Can fig build an image with no service/container associated ?

[dridi]

I'm just starting with fig so it may just be a case of not reading properly the docs, but I haven't found out how to just build an image with fig. I'm trying to replace a make-based approach after someone told me a couple months ago that I was basically doing what fig does. I was also waiting for fig 1.0 to land in Fedora, which is almost there.

But I have a base image, which is basically based on centos:centos6, installs and enables EPEL, and a private YUM repository. I use this image as a base for all the containers, and incidentally benefit from caching and DRY.

Conceptually, it looks a bit like this:

find . -name Dockerfile
./base/Dockerfile
./db/Dockerfile
./front/Dockerfile

Now I can create and run db and front containers, and link them together, but I have built the base image separately. There is no base container.

Did I miss something?

[aanand]

If there's a base container defined in fig.yml, it should definitely have been created. So:

• Have you defined a base container in fig.yml? (if possible, could you paste the whole file here?)
• If so, what's the output of docker ps -a?

[dridi]

There is no base container, the base image contains the common bits for all other images. It is not meant to run anything by itself.

I build the base image using: docker build -t stuff/base base.

The other images' Dockerfiles start with FROM stuff/base.

[aanand]

Sorry, I originally read "There is no base container" as your description of the problem :)

If I have it right, you're not actually trying to run your containers, just build the images for them. If so, whoever told you that was Fig's job was mistaken - Fig is for running containers, and the image-building functionality only goes far as it needs to in order to enable that.

[dridi]

He was not mistaken, he told me I could use fig to manage containers in a declarative way instead of my make-based approach. And it works well!

So I guess I have my answer, fig can't build arbitrary images and handle dependencies between such images and container images. Am I right?

[aanand]

That's right. There's talk about enabling that at the Docker level - see moby/moby#735 - but I don't really think it's Fig's job.

[ghost]

I use the following pattern in project/docker-compose.yml. It seems to be working.

mariadb:
  build: mariadb/
  volumes:
    - /etc/mysql
    - /var/lib/mysql
  ports:
    - "3306:3306"

django:
  build: django/
  command: /bin/true

app1:
  image: project_django
  links:
    - mariadb
    - django
  ports:
    - "8000"

[fruch]

@DarkerMatter
+1 for the hack of using /bin/true
(but why does the app1 links django ?, it's a mistake ?)

[fruch]

@aanand
look at:
https://github.com/michaelsauter/crane
the provision command, can do that
I've seen people build up complex hierarchy of dockerfiles like that.

Yes using a private docker-registry might be more advisable solution, but I think this kind of pattern can have it's place
For it's lighter cases, or as a preparation stage to get the feeling of how the structure should look like before setting up registry with version and tags, and the whole shebang.

[ghost]

@fruch app1 is just an example of using the django image created. For instance app2 could have different volumes/db/ports, etc.

[ghost]

@fruch also, as fig/compose works out the dependencies, it makes sure that the django image is built before app1 in a fresh installation

[dnephin]

Related to #295, #610, #583

[dminkovsky]

@dridi did you ever solve this? Specifically:

I build the base image using: docker build -t stuff/base base.

The other images' Dockerfiles start with FROM stuff/base.

[dridi]

From what I can remember from two-ish years ago, I tried to hack on fig to add a way to express dependencies between images but didn't manage to reliably do it because there were too many moving parts. Building the dependency graph by reading the FROM clause of the Dockerfiles was also feeling somewhat wrong.

Then my use case retired. By the time I was done with it my Makefile had been good-enough and I moved on to other work.

Looking at @DarkerMatter's workaround, it could work and help create the base image at the expense of creating a throwaway container. I'm not sure it would guarantee the image creation order. I haven't tried.

Sorry

[dminkovsky]

@dridi I figured this was long ago, far away for you at this point :). Yeah, I just have a shell script that builds these base images. Definitely good enough.

Thank you!