Version control of Docker images #604
Comments
|
This would also shorten the travis builds duration time. Because there would be no need to mount the docker image every time we trigger a travis build |
|
@alaxalves I don't work with the docker setup personally so @icarito would be the person to answer this, but just to better understand the discussion: in Plots2, which has a more complete Docker setup, are we just managing different environments and the services we need for each by having multiple configuration files ( |
|
@sashadev-sky I wouldn't be something like in https://github.com/publiclab/plots2/. What I actually mean in this issue is for us to have a version control of our docker images just like I have for Klara-API project here. See that I have different versions of my images, to accomplish it I have simply built the images and pushed to my personal DockerHub registry, and those images are used in my yml file here. So I don't have to build my image all the time. By having this control we could easily rollback to an image version, for instance. Also, I would improve the travis workflow I suggested in #598 and in #605 (comment). We could have images for our CI, development and production env, for instance. This is a very common practice among orgs, that's what enables us to use Ruby's image in our Dockerfiles for example. It would make easier to another org(or even for us), for example, to create another work on top of our Mapknitter docker image, just by doing this in some Dockerfile: I suggested that we create an org on Dockerhub an start publishing our docker images there and gradually switch in our ymls to start using those images. |
Actually I'd like to do the same work I'd like to accomplish here in Plots2 too. Stuff like #604 #598 would apply to plots2 in a certain way too. |
|
Hi, this is interesting and I think @icarito has mentioned some of these
possibilities. I think he is the best person to provide input on this.
Would there be any version sync issues with running Travis on the latest
code? I'm just not that familiar with Docker myself. And, noting, the
plots2 files are in /containers/docker-compose-______.yml -- hope that
helps!
…On Wed, May 15, 2019 at 9:25 AM Álax de Carvalho Alves < ***@***.***> wrote:
@alaxalves <https://github.com/alaxalves> I don't work with the docker
setup personally so @icarito <https://github.com/icarito> would be the
person to answer this, but just to better understand the discussion: in
Plots2, which has a more complete Docker setup, are we just managing
different environments and the services we need for each by having multiple
configuration files (docker-compose-production.yml
docker-compose-stable.yml, etc.)? But the underlying issues with
environment management you want to improve are still there as well?
Actually I'd like to do the same work I'd like to accomplish here in Plot2
too. Stuff like #604 <#604>
#598 <#598> would apply to
plots2 in a certain way too.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#604?email_source=notifications&email_token=AAAF6J3Y27MRIU5KG6KU62LPVQFKRA5CNFSM4HM5FVK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVOUTLQ#issuecomment-492652974>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAF6JZU4LQWKJGJXDZ5A63PVQFKRANCNFSM4HM5FVKQ>
.
|
Actually we use tag the images as we want, and Travis would use the version defined in our yml file. I'd love to pair up with @icarito and get this train rolling. |
|
@alaxalves that sounds like a plan, although emphasizing @icarito is your guy here haha Another question, would these be held in a private or public repo? |
Well, registries are usually public such as https://hub.docker.com/_/ruby/ are made public to make our imaeg available to everyone else in the community. |
|
|
|
Just so we can all be on the same page here, would you mind drawing us a
diagram of how the image in the registry is updated, where Travis pulls
from, and where a PR stands in relation to the versions of the image?
Thanks a lot, Alax!
…On Thu, May 16, 2019 at 6:31 PM Álax de Carvalho Alves < ***@***.***> wrote:
[image: image]
<https://user-images.githubusercontent.com/19597045/57891212-f9f67800-7810-11e9-8734-d9c1710c1da6.png>
Just recording this here. I'll work on it. 💪
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#604?email_source=notifications&email_token=AAAF6J27655C6DOECGJ42KDPVXOABA5CNFSM4HM5FVK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVTHI3A#issuecomment-493253740>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAF6J5Y4U3BSFH55Z33NE3PVXOABANCNFSM4HM5FVKQ>
.
|
No problem @jywarren, I'll do it and upload it here. ;) |
|
Hi @alaxalves actually this is something we want! The devil is in the details! I did some work in this direction - but we need to put everything in ENV variables and iron out details! |
@jywarren So here I used Plots2 and Mapknitter as an example of what I want to accomplish here.
In a computer somewhere, inside mapknitter project folder: After building our image and making it available on our PublicLab Registry on https://hub.docker.com/u/publiclab (for example), we could start using it on our docker-compose yaml files. By start versioning our images like this, our users could use the Mapknitter version they want, we could also make our code easier to contribute since one could easily do this in its Dockerfile: This would impact on our Travis runtime, by making it way shorter than it is today, that is because Travis would not need to build our image everytime like this (Line 452 to 1089) https://travis-ci.org/publiclab/mapknitter/jobs/533555347#L452. All Travis would need is to and it could continue with the following steps of our build. How the image in the registry is updated? Where Travis pulls it from? Were a PR stands in relation to the versions of the image? |
|
I have already done the image upload at: https://cloud.docker.com/u/publiclab/repository/docker/publiclab/mapknitter |
|
Mostly of this has been motivated because we were fully using docker in test env. But since #672 this is kinda not needed anymore. |
I have been working on #598 and #599 and have realized that it would be a great idea if we create a registry account for publiclab org(in dockerhub for instance) and manage our docker images from there, instead of building our images every time we need to lift our environment (either production, tests ran in travis or development(which we dont have docker env for)) somewhere. It would make our environment management SO MUCH easier just by tagging our images version. Currently we have no control of previous images we've used before. What do you think guys @cesswairimu @jywarren @icarito @sashadev-sky @SidharthBansal ??
The text was updated successfully, but these errors were encountered: