New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Dridi opened this Issue Nov 21, 2014 · 14 comments

Comments

Projects
None yet
6 participants
@Dridi

Dridi commented Nov 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Nov 21, 2014

Contributor

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?
Contributor

aanand commented Nov 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Nov 21, 2014

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.

Dridi commented Nov 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Nov 21, 2014

Contributor

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.

Contributor

aanand commented Nov 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Nov 21, 2014

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?

Dridi commented Nov 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Nov 23, 2014

Contributor

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.

Contributor

aanand commented Nov 23, 2014

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.

@darkermatter

This comment has been minimized.

Show comment
Hide comment
@darkermatter

darkermatter Feb 18, 2015

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"

darkermatter commented Feb 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@fruch

fruch Apr 14, 2015

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

fruch commented Apr 14, 2015

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

@fruch

This comment has been minimized.

Show comment
Hide comment
@fruch

fruch Apr 14, 2015

@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.

fruch commented Apr 14, 2015

@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.

@darkermatter

This comment has been minimized.

Show comment
Hide comment
@darkermatter

darkermatter Apr 15, 2015

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

darkermatter commented Apr 15, 2015

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

@darkermatter

This comment has been minimized.

Show comment
Hide comment
@darkermatter

darkermatter Apr 15, 2015

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

darkermatter commented Apr 15, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Sep 18, 2015

Contributor

Related to #295, #610, #583

Contributor

dnephin commented Sep 18, 2015

Related to #295, #610, #583

@dnephin dnephin closed this Sep 18, 2015

@dminkovsky

This comment has been minimized.

Show comment
Hide comment
@dminkovsky

dminkovsky Sep 23, 2016

@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.

dminkovsky commented Sep 23, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Sep 23, 2016

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

Dridi commented Sep 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dminkovsky

dminkovsky Sep 23, 2016

@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!

dminkovsky commented Sep 23, 2016

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment