Fedora Account System
Red Hat Associate
Red Hat Customer
Dockerfile URL: https://hhorak.fedorapeople.org/ruby-docker/Dockerfile Other files URL: https://hhorak.fedorapeople.org/ruby-docker/ Description: This container image provides a platform for building and running Ruby application as a reproducible image using source-to-image. Ruby is the interpreted scripting language for quick and easy object-oriented programming. It has many features to process text files and to do system management tasks (as in Perl). It is simple, straight-forward, and extensible. Fedora Account System Username: hhorak
Just two quick comments: 1) FROM 25/s2i-base - Why is the "25" hardcoded? Isn't this supposed to follow the Fedora releases? 2) "This image provides a Ruby 2.4 environment" but it seems you later install Ruby 2.3. Anyway, where is this going to live? What is the workflow? Why just Ruby 2.3 and no other Rubies?
And why is it "package review" when you are asking for container/dockerfile review?
(In reply to Vít Ondruch from comment #1) > Just two quick comments: > > 1) FROM 25/s2i-base - Why is the "25" hardcoded? Isn't this supposed to > follow the Fedora releases? Every image will live under a namespace ("25" in this case) in the fedora registry, see: https://fedoraproject.org/wiki/Container:Guidelines > 2) "This image provides a Ruby 2.4 environment" but it seems you later > install Ruby 2.3. Particular ruby version will depend on Fedora version. You're right that for F25 it is ruby 2.3. Fixed now. > Anyway, where is this going to live? What is the workflow? Why just Ruby 2.3 > and no other Rubies? It should be compatible with what RHSCL images provide. It will live in fedore registry, see more at: https://fedoraproject.org/wiki/Container:Review_Process https://fedoraproject.org/wiki/Container:Guidelines (In reply to Vít Ondruch from comment #2) > And why is it "package review" when you are asking for container/dockerfile > review? I guess before it was the same process, now I see different product, so changing.
* Few labels are missing: [1] BZComponent, RUN or Usage, Help * Version label should be set to 0 [2] * help file missing [3] * Please use "LABEL MAINTAINER" instead of "MAINTAINER" build command (BTW it is deprecated in latest docker releases) [1] https://fedoraproject.org/wiki/Container:Guidelines#LABELS [2] https://fedoraproject.org/wiki/Container:Guidelines#VERSIONING [3] https://fedoraproject.org/wiki/Container:Guidelines#Help_File
(In reply to Honza Horak from comment #3) > (In reply to Vít Ondruch from comment #1) > > Just two quick comments: > > > > 1) FROM 25/s2i-base - Why is the "25" hardcoded? Isn't this supposed to > > follow the Fedora releases? > > Every image will live under a namespace ("25" in this case) in the fedora > registry, see: > https://fedoraproject.org/wiki/Container:Guidelines This does not answer my question. The line should be IMO something like "FROM ${dist}/s2i-base" or whatever is appropriate for Dockerfile, so you don't have to update the file between releases.
(In reply to Vít Ondruch from comment #5) > This does not answer my question. The line should be IMO something like > "FROM ${dist}/s2i-base" or whatever is appropriate for Dockerfile, so you > don't have to update the file between releases. It is not possible in Dockerfile :-( For example "$DISTTAG is defined just as it is for RPMs, but since Dockerfiles lack a mechanism similar to RPM Macros this is being stored in the base image such that it can be inherited by layered images. "[1] So similar thing can be stored in base image (used to define labels based on Fedora release - "LABEL Name="$FGC/mycontainer"; $FGC is set to F26, F27, ...). But there is no other way how to obtain these env variables than "inheriting" them from base image. So definition of base image have to be hard-coded. [1] https://fedoraproject.org/wiki/Container:Guidelines#LABELS
(In reply to Marek Skalický from comment #6) > (In reply to Vít Ondruch from comment #5) > > This does not answer my question. The line should be IMO something like > > "FROM ${dist}/s2i-base" or whatever is appropriate for Dockerfile, so you > > don't have to update the file between releases. > > It is not possible in Dockerfile :-( Isn't this something what should be supported by OSBS or whatever is building the images?
* Docker docs say 'MAINTAINER (deprecated)'. And claims we should rather use LABEL maintainer ... * All the examples in guidelines tell about 'FROM: fedora:25', not 'FROM: 25' * guidelines tell us to install software from RPMs provided by RPMs, but that statement should be probably relaxed: The Fedora Layered Image Build Service will reject images that are found to be built from sets of software not provided by Koji .... Vít Ondruch wrote: > Isn't this something what should be supported by OSBS or whatever is building > the images? That sounds like political question. Dockerfiles have poor design (e.g. we can not use docker build --build-arg for this), so when we decided that Dockerfiles are equivalent to "what spec file is in rpm world", we need to make sure that 'docker build' support such features ... IOW, doing some nasty 'sed -i s/FROM.*/.../ Dockerfile' in osbs would make the builds non-reproducible. The other option is to invent some well-known templating system and start "generating" Dockerfiles. That's what was rejected many times when I proposed that. So the simple answer is that, based on the political rules, we need to hard-wire.
Sources updated: Dockerfile URL: https://hhorak.fedorapeople.org/ruby-docker/Dockerfile Other files URL: https://hhorak.fedorapeople.org/ruby-docker/ (In reply to Marek Skalický from comment #4) > * Few labels are missing: [1] > BZComponent, RUN or Usage, Help > * Version label should be set to 0 [2] > * help file missing [3] All fixed now: ... ENV NAME=ruby \ VERSION=0 \ RELEASE=1 \ ARCH=x86_64 LABEL BZComponent="$NAME" \ Name="$FGC/$NAME" \ Version="$VERSION" \ Release="$RELEASE.$DISTTAG" \ Architecture="$ARCH" \ Usage="s2i build file:///your/app 25/ruby your-app" \ Help="help.1" ... > * Please use "LABEL MAINTAINER" instead of "MAINTAINER" build command (BTW > it is deprecated in latest docker releases) Also fixed. (In reply to Pavel Raiskup from comment #8) > * All the examples in guidelines tell about 'FROM: fedora:25', not 'FROM: 25' It's not only FROM 25, it's FROM 25/s2i-base, since that is the name which the s2i-base will be available under. > * guidelines tell us to install software from RPMs provided by RPMs, but > that statement should be probably relaxed: The Fedora Layered Image Build > Service will reject images that are found to be built from sets of software > not provided by Koji .... Yeah, some starting scripts are fine, my interpretation is that we should not include big chunk of data or compile applications from source in Dockerfiles.. > Vít Ondruch wrote: > > Isn't this something what should be supported by OSBS or whatever is building > > the images? This is not proper place to discuss this, feel free to bring this topic to cloud SIG, so the guidelines can be changed: https://fedoraproject.org/wiki/Container:Guidelines
Today I read the guidelines again and found this sentence: "The FROM instruction must be fully-qualified with a registry name, image name, and tag as shown in this example: FROM registry.example.com/imagename:tag " It says that image tag must be there. On the other hand ":latest" is the default in Docker. So I don't know what to thing about this rule.
Correct, using :latest as it is also used in the examples: FROM registry.fedoraproject.org/f25/kubernetes-master:latest (https://fedoraproject.org/wiki/Container:Guidelines#FROM) Should be fixed now.
I also asked on #fedora-cloud and they told me, that :latest is required. Thanks, for updating it.
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/container/ruby