#217 RFE: Docker dev stack on Docker Hub
Closed: Won't fix 3 years ago by msuchy. Opened 6 years ago by frostyx.

I really wish to have docker stack from ./docker directory on Docker Hub.

Advantages:

  • CI, we would easily see whether changes in the project break the docker stack. Now we usually find out when someone new tries to build it
  • Reduce the time required to setup the environment. This doesn't have to be a big deal when using it on developer machines, but if we want to use the docker stack in beaker tests in the future, it may be very helpful there.
  • Possibility to run the latest successfully built image when there is some problem and it is not possible to build the image from master

I think that the advantages highly prevail the troubles of settings this up.


I was interested in how the docker-compose will work with Docker Hub, as I've never used it before and I want to present you my findings.

I created the fedoracopr/copr-frontend repository (just copr was taken and the website didn't let me create fedora-copr like we have on GitHub, so ... fedoracopr). Then I set image: fedoracopr/copr-frontend for the frontend service in docker-compose.yaml. I've built it and manually pushed to the docker hub, cause I didn't want to create webhook yet.

Then it behaves this way

  • docker-compose pull and docker-compose up downloads the images (so far just frontend) from docker hub and then runs them, i.e. no building on user machine
  • docker-compose up without pulling first, builds the images on a user machine and then runs them, i.e. does exactly what we have now in master.

Do you like it? Should I create repos for all the docker-compose services and setup webhooks, so the images are rebuilt on each commit?


We should really do this with ansible(-container) scripts instead of docker scripts and put those up on https://galaxy.ansible.com/. One reason might be that Ansible is basically a RedHat's own technology and we should prefer that. Also there are already ansible playbooks in Fedora Infra Git and these two things could become the single one eventually. If we had a working CI, I would definitely like to base it on setup scripts written in Ansible. The advantage is also that those same (tested) scripts might then be given to somebody to setup his/her bare-metal servers with the COPR stack. Of course, if you want to put up the docker repos on dockerhub.io, why not but it's not something that I see as future technology for our CI and testing (unless we can get the images on dockerhub updated by the roles present in Ansible Galaxy - if that is possible then that could be cool but I would still probably prefer using Fedora Image Registry instead of dockerhub.io). I think rewriting those docker setups into Ansible should be our focus already but they can also exist side-by-side, I guess, if we keep them up-to-date both.

I am aware that you want to have that docker stack managed by ansible playbooks. I like the idea too, because of the reasons that you just mentioned. But I believe that dockerhub and ansible galaxy are not mutually exclusive (or I understand the ansible galaxy wrong).

You basically say it here

Of course, if you want to put up the docker repos on dockerhub.io, why not but it's not something that I see as future technology for our CI and testing (unless we can get the images on dockerhub updated by the roles present in Ansible Galaxy - if that is possible then that could be cool but I would still probably prefer using Fedora Image Registry instead of dockerhub.io)

I want to break it down a bit

but it's not something that I see as future technology for our CI and testing

CI is one thing, but there are few difficulties of the docker stack that are not CI related. 1) It takes an unnecessarily long time to build all the images; 2) It can happen, that docker-compose build doesn't work for particular commit in master, which is actually problem for two reasons. When some change breaks it and some of the images can no longer be built, it can be simply overlooked by the author of that change and meanwhile it is pain for other devs to get the images.

Everything of this can be easily solved by using a service to build the images for us. Agree?

unless we can get the images on dockerhub updated by the roles present in Ansible Galaxy - if that is possible then that could be cool

That is my idea. I mean ... I can't say that it will work because I've never done it yet, but why it shouldn't work? However, that's the goal.

I would still probably prefer using Fedora Image Registry instead of dockerhub.io

If we really want to use it, I can examine it. The reason why I chose dockerhub is simple - To find out URL of Fedora Image Registry took me almost 30 minutes (is it even right https://registry.fedoraproject.org/ ?), I have no clue how to create a new project on it and project details give 404. On the other hand, I've spent same 30 minutes on dockerhub and have a built image on it and tested it with docker-compose.

I am aware that you want to have that docker stack managed by ansible playbooks. I like the idea too, because of the reasons that you just mentioned. But I believe that dockerhub and ansible galaxy are not mutually exclusive (or I understand the ansible galaxy wrong).

I suspect they are not mutually exclusive (because AnsibleGalaxy doesn't store images it seems, only sources). But I don't know how I would integrate them together.

CI is one thing, but there are few difficulties of the docker stack that are not CI related. 1) It takes an unnecessarily long time to build all the images; 2) It can happen, that docker-compose build doesn't work for particular commit in master, which is actually problem for two reasons. When some change breaks it and some of the images can no longer be built, it can be simply overlooked by the author of that change and meanwhile it is pain for other devs to get the images.

It shouldn't really happen that the problem is overlooked. Ideally we have a testing environment that we maintain 100%, is up-to-date and is working all the time.

Everything of this can be easily solved by using a service to build the images for us. Agree?

Well, ye, we need this automation if we want to spawn the stack after each commit or PR. It would be nice to have that image-building part done by COPR itself (there is a card in our Trello about this) but if that proves not to be possible then we will need some other service.

Thank you for looking at it, by the way.

Automatic re-build of image(s) is a good idea. +1. Please share them both in docker and fedora registry, why not (if that's legally possible).

More, I would like to have something like copr/frontend_base image, updated regularly (say weekly). Such image would be ready to take, and install the only missing part (copr-frontend package). Generating coprfrontend image would be really quick then even from git.

Btw., the "service" (frontend, backend, dist-git, ...) is a black box which as its inputs/outputs. Moving from runtime to runtime is just disturbing, we should be able to pick the runtime (libvirt, docker, ansible, ...), whatever is more appropriate for concrete situation. Test-cases should only deal with the inputs/outputs.

I don't think we should prefer one container technology over other, but if we really have to we should think about cri-o rather than about ansible, and docker as a first step towards that.

Please share them both in docker and fedora registry, why not (if that's legally possible).

Yeah, that is actually a good idea, why not? +1 from me. In such case, we need to decide which of them will docker-compose use. It shouldn't really matter though, I just wanted to point it out.

More, I would like to have something like copr/frontend_base image, updated regularly (say weekly). ...

True, but I would see this as a future idea since it solves only a build time. Having solved this RFE, build time will not be that much problem anymore, cause it won't be done on a user machine.

Btw., the "service" (frontend, backend, dist-git, ...) is a black box which as its inputs/outputs.

In that context I meant the word "service" as a docker-compose service :-)

Btw., the "service" (frontend, backend, dist-git, ...) is a black box which as its inputs/outputs. Moving from runtime to runtime is just disturbing, we should be able to pick the runtime (libvirt, docker, ansible, ...), whatever is more appropriate for concrete situation. Test-cases should only deal with the inputs/outputs.

but yes, this is true. The problem is how to define those blackboxes, so they could be written just once and used everywhere. Ansible sound like a good candidate. We probably could provision the docker images by running the playbooks in them, vagrant has ansible provider, ... However, I kind of disagree with @clime here, regarding the order in which we should do things. I think that re-writing the playbooks will be time consuming (even though we already have working Dockerfiles and roles for dev and production machines), so I would like to have a proper planning there. On the other hand this RFE could be done easily, so personally, I would prioritize this.

True, but I would see this as a future idea since it solves only a build time. Having solved this RFE, build time will not be that much problem anymore, cause it won't be done on a user machine.

Yes, it can be future RFE (complementing this one), but let me point out that build time is huge issue even now -- for example for contributor before sending pull-request. In this case, pre-build images in registry do not help. Btw., it would be nice to automatically test pull-requests in future, and thus we should make "finalization" build-time fast enough ...

but yes, this is true. The problem is how to define those blackboxes, so they could be written just once and used everywhere.

I would go with essential way; inputs/outputs are config files, ports, log files, etc. Btw., things like redis/postgresql should live in separate black-boxes.

Regarding the playbooks rewrite ... if, by playbooks, you mean the large scripts setting up whole fedora copr stack (development or production), I want to point out that playbooks are just deployment specific scripts. Whoever wants to deploy the service will write new deployment scripts... I don't think fixing the playbooks to work for CI purposes, too, is worth the pain (ansible really sucks here).
At the end of the day, installation of copr should be about package installation and configuration. Anything else (starting postgres somewhere, allocating volumes and mounting them, etc... all this is deployment specific stuff which nobody will share with us, and probably it doesn't make sense to share that with CI neither).

However, I kind of disagree with @clime here, regarding the order in which we should do things. I think that re-writing the playbooks will be time consuming (even though we already have working Dockerfiles and roles for dev and production machines)

It will take some time, yes, but I think a well invested time. Having the test stack written in ansible is the most important factor for us because we can use those same scripts to deploy virtual machines, bare-metal servers, or just system containers. It will take a bit of time to get there but it would be good to start with some prototype (that works just as a test stack) already now. It will be something that we can also give to people and say: "This is how you deploy COPR" which is also something very useful.

Deploying copr should be as easy as installing the copr packages + editing configs. Every other customization is deployment-specific, and I really wouldn't waste the time on making the deployment-specific scripts a generic scripts; this is not what ansible is designed for.

Deploying copr should be as easy as installing the copr packages + editing configs. Every other customization is deployment-specific, and I really wouldn't waste the time on making the deployment-specific scripts a generic scripts; this is not what ansible is designed for.

I recommend to you going through http://docs.ansible.com/ and trying a few things out on your own so that you get more familiar with the topic. Especially pay attention to how variables work in Ansible and how you can use them to create more generic scripts.

I know what am I saying about ansible ;-). Please solve the real issues. If deploying basic
copr stack is anything else then installing package and configuration, something is wrong.
Anyways, it won't be me who will waste the time here, I'm just observer...

I know what am I saying about ansible ;-). Please solve the real issues. If deploying basic
copr stack is anything else then installing package and configuration, something is wrong.
Anyways, it won't be me who will waste the time here, I'm just observer...

Ok, sorry then, based on you activity in chat I thought you were somehow involved in the project.

Since I know how much deployment-specific your playbooks are (I'm maintaining
my own playbooks), I'm just trying to convince you that no matter how you'll CI
the playbooks, i'll have my own deployment-specific troubles so it is unlikely
I'll use them. Please accept my note that we could make the deployment a bit
easier (and faster, see #185 discussion).

Sooo :-) no, I'm still here in the project. I'm just stepping down in another PR where
I can not help more.

i'll have my own deployment-specific troubles so it is unlikely I'll use them.

Well, even if you need to make some tweaks it is still good to have something as a starting point.

Unfortunate work-around. It should be as easy as installing the package + config.

Metadata Update from @frostyx:
- Issue tagged with: RFE

5 years ago

I am going to close this. We did not have time for this in past years. And it will likely not change in the upcoming several years.

Metadata Update from @msuchy:
- Issue close_status updated to: Won't fix
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata