Skip to content
This repository has been archived by the owner on Dec 13, 2018. It is now read-only.

Conex support for multiple images in the same repo #121

Open
jakepruitt opened this issue Mar 8, 2018 · 6 comments
Open

Conex support for multiple images in the same repo #121

jakepruitt opened this issue Mar 8, 2018 · 6 comments

Comments

@jakepruitt
Copy link

Conex currently only builds one container per repo.

We have a repo, we'll call it tabby-cat, which defines multiple containers and uses docker-compose as well as custom bash scripts to build and push the multiple images to ECR. The multiple images are tagged with:

tabby-cat:<git-sha>-rails
tabby-cat:<git-sha>-cgimap
tabby-cat:<git-sha>-orcd

where each of those sub-images is defined in a different part of the services section of the docker-compose.yml file.

It would be great if we could rewrite conex to support multiple containers.

Plan for how to do this

The outputs of docker-compose build are multiple images with the format tabby-cat_rails, tabby-cat_cgimap, etc., where tabby-cat is the name of the folder and rails is the name of the section of the docker compose file. Using some string transformations, I think we could re-tag these images with the <repo>:<gitsha>-<subimage> format and push all of them to ECR.

cc/ @Yuffster @rclark

@rclark
Copy link
Contributor

rclark commented Mar 9, 2018

Would there be a convention about Dockerfile locations within a repository, or would conex parse a docker-compose file?

@jakepruitt
Copy link
Author

I don't think any parsing or conventions would be necessary: the docker-compose file defines where each image's context/Dockerfile lives and outputs all of those images in the format <folder-name>-<image-name> when running docker-compose build.

@rclark
Copy link
Contributor

rclark commented Mar 9, 2018

Oh I see -- so you're imagining that conex will run docker-compose build.

Once they're built, how would it know what it needs to retag & upload? If the image is <folder-name>-<image-name>, does that folder-name refer to where the Dockerfile was that built that image, or to the name of the folder containing the docker-compose file? If the prefix is consistent, then docker images --filter can likely find the images to upload.

@Yuffster
Copy link

Yuffster commented Mar 9, 2018

It's the folder that the docker-compose file is in, which is nice because it leaves the actual Dockerfile locations up to the developer.

Currently I'm doing something like...

docker images --format '{{.Repository}}' | grep tabularasa
tabularasa_nginx
tabularasa_osmosis
tabularasa_cgimap
tabularasa_postgis
tabularasa_rails

And if I rename the folder...

cd ../
mv tabula-rasa nottabularasa
docker images --format '{{.Repository}}' | grep tabularasa
nottabularasa_nginx
nottabularasa_osmosis
nottabularasa_cgimap
nottabularasa_postgis
nottabularasa_rails

@rmrice
Copy link

rmrice commented Apr 10, 2018

This is a great idea that would be beneficial for project scalability and supporting different environments. Any movement on this?

@jakepruitt
Copy link
Author

@rmrice @Yuffster I don't think this will be on anyone's roadmap until the end of May. I think the outline above would hopefully be enough to get started if either of you wanted to give it a shot before then.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants