#84 Care and Feeding, Fedora Dockerfiles
Closed None Opened 4 years ago by mattdm.

https://github.com/fedora-cloud/Fedora-Dockerfiles is

a) cool
b) useful
c) active
d) a great place for new contributors

We should popularize this. Articles, blog posts, wiki documentation, non-wiki documentation, etc.


I think that's a great idea. Opportunities for contributions:

a) Once we get the systemd in containers all figured out, we'll need to do a massive conversion for all examples using supservisord.
b) Some of the Dockerfiles haven't been tested since < 1.0. Images have been built, but not necessarily run and carefully looked at.
c) README's could be cleaned up a bit and standardized further
d) The examples are really single service focused. Would be cool to have some folks tie together these services and create some complex apps for demo / learning purposes. Then figure out some way to save that for others to test.
e) and we are always looking for new examples / contributions!

Keep in mind, this feeds both the fedora-dockerfiles package as well as some of the images on the Docker hub.

We can work this into the release announcement if we're confident that the bulk of the dockerfiles are actually updated + good to go.

@jzb, I'm pretty confident on where we are with the files.

Random Question.. I feel like one goal of promoting these is to promote F21/Atomic as well as their support of Docker. Should we wait to heavily promote these until many of the dockerfiles have been updated to use Fedora's official Docker base image (the first one being from F21) rather than the F20 image created by Marek?

Replying to [comment:4 dustymabe]:

Random Question.. I feel like one goal of promoting these is to promote F21/Atomic as well as their support of Docker. Should we wait to heavily promote these until many of the dockerfiles have been updated to use Fedora's official Docker base image (the first one being from F21) rather than the F20 image created by Marek?

We should definitely do that update. I don't know how much we want to wait based on that, though.

Discussed during today's meeting. I'm taking this ticket and will come up with a general plan for promoting these around the release and beyond.

Breaking this down into individual tickets.

Fedora Magazine Post: How to use dockerfiles - https://fedorahosted.org/cloud/ticket/87
Social media: https://fedorahosted.org/cloud/ticket/88
Dockerfile section downloads page? https://fedorahosted.org/cloud/ticket/89

Potential articles / headlines:

"Fedora Images on Docker Hub"
"How to Contribute Dockerfiles - What's Needed?"
"Using CI to Build and Verify Dockerfiles"

Potential articles / headlines:

"Connecting Services in Docker Images"

I'm just starting to look at the fedora-dockerfiles. I managed to get the Firefox one running but it was a struggle - vnc in a Docker container's non-trivial. The Redis and PostgreSQL ones are high on my list to get working.

However, if the licensing and trademark folks don't have major issues with it, you're welcome to use my 'osjourno-rd' project as an example. See http://www.rstudio.com/about/trademark/ for the IP issues and https://registry.hub.docker.com/u/znmeb/osjourno-rd/ for the project itself.

Posted the 101-level piece today on Fedora Magazine, promoted on Twitter.

Unless someone screams "no" - I'm changing this ticket title to "care and feeding" to manage multiple issues related to Dockerfiles. (Old title "publicize fedora-dockerfiles")

Adding an issue:

  • f22 docker image does not have yum. We need to deal with updating all images to use dnf instead of yum.

I'll sign up to do testing for sure, starting with the PostgreSQL one. That's on my roadmap with PostGIS added. The "Firefox" one would be nice to have but PostgreSQL/PostGIS is the only one I know I'll need. I do have it working on F21 if you want some PR for that.

I don't see the F22 Docker image on Docker Hub - the Rawhide image is there, however, and IIRC it has yum and not dnf. So a subtask to this issue is getting an F22 image posted to Docker Hub.

As discussed today in Cloud Meeting - we're still more or less where we were six months ago. We need to break these out in separate tickets and start working them that way. Will revisit this once we have a new repo tested / broken out for centos/fedora dockerfiles.

For maintaining the dockerfiles we need to create branches for Fedora releases so that they can be maintained without effecting each other. I have sent the suggestion on cloud sig mailing list [1]. The thread should give enough information about the idea.

[1] https://lists.fedoraproject.org/pipermail/cloud/2015-July/005603.html

Replying to [comment:15 lalatendu]:

For maintaining the dockerfiles we need to create branches for Fedora releases so that they can be maintained without effecting each other. I have sent the suggestion on cloud sig mailing list [1]. The thread should give enough information about the idea.

[1] https://lists.fedoraproject.org/pipermail/cloud/2015-July/005603.html

Created:

Master:
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master

F21:
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/f21

F22
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/f22

I have not made any changes to the branches yet. We need someone to test the conversion to DNF. I also would like to bring up CI again here. That would help immensely.

Replying to [comment:16 scollier]:

We need someone to test the conversion to DNF. I also would like to bring up CI again here. That would help immensely.
What is the goal of CI?

If all we want is a way to try building the image from the dockerfile and mark as successful if image is built, then I can write a script to look for Dockerfile and do the needful. But if the idea is to check the sanity of the image, for example, fire up containers from the image and check if the image is working as '''expected''', then it can be a tough deal.

Replying to [comment:17 adimania]:

If all we want is a way to try building the image from the dockerfile and mark as successful if image is built, then I can write a script to look for Dockerfile and do the needful. But if the idea is to check the sanity of the image, for example, fire up containers from the image and check if the image is working as '''expected''', then it can be a tough deal.

Not speaking for Scott, but I it'd be very helpful to start with that simple build check, and then go more complicated for there. (Let's not let complicated end goals stop us from doing the quick things now.)

I wrote this [https://gist.github.com/adimania/6965be099904433f626f script] to build all the images from dockerfile and ran it on the master branch of the git repo. I can modify it to run on any branch. The following failed to build:

{{{
firefox failed to build
libvirt failed to build
mesos master failed to build
mesos slave failed to build
haskell failed to build
hadoop failed to build
mysql failed to build
}}}

I checked the build logs and almost all of the above failed due to broken package dependencies. [[BR]]
Please have a look at the script and let me know if I am doing anything wrong. I would try to fix some of these Dockerfiles but I have no experience with Hadoop or Haskell or Mesos. So I might not be able to fix all of them.

I have been working on f22 branch to move it to dnf and to clear out issues in the build test that I wrote. For this weekend, here are the findings for f22 branch:
replaced yum with dnf
forcing the use of fedora 22 for f22 branch. The current Dockerfiles have various images hardcoded, including rhel in one of the files.
ran the build test from https://gist.github.com/adimania/6965be099904433f626f. Following images failed to build due to package dependencies:
* firefox
* container-best-practices
* haskell
I have removed pdftk since that is no longer packaged for f22.
The pull request for the changes is [https://github.com/fedora-cloud/Fedora-Dockerfiles/pull/133 here]

PS: Note that I had to run a couple of failed cases manually. There is a corner case which is being missed in the build script. I will fix that shortly.

This ticket has been split into more granular tickets (Thanks scollier!). Closing.

Login to comment on this ticket.

Metadata