Skip to content

Using OracleLinux as a base #289

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ltangvald opened this issue Apr 26, 2017 · 8 comments · Fixed by #680
Closed

Using OracleLinux as a base #289

ltangvald opened this issue Apr 26, 2017 · 8 comments · Fixed by #680
Labels
Request Request for image modification or feature

Comments

@ltangvald
Copy link
Collaborator

This isn't a bug, more meant for discussion.

We've talked a bit about this before, but then there was less benefit to switching. With the new slim base images of OracleLinux, it may be of value to consider switching/adding variants, so I will just try to summarize pros and cons.

Pros:

  • Image size is roughly halved. ol-slim is of comparable size to debian, while the custom Docker rpms on repo.mysql.com are much smaller than the standard Debian packages we use now. For 8.0 however there are the new -core packages for Debian that give the same size benefit (PR Use new -core packages for 8.0.1+ #282)
  • Rpm package is more standardized across all major server versions. No need for the generic linux package used for 5.5

Cons:

  • No apt. OracleLinux has yum. This is the big one, as it will break any image that uses FROM mysql, and then runs apt-anything.
  • Risk of breaking other use cases that work on Debian but not rhel-based systems.

Possible ways to do it:

  • Switch all: I don't really consider this an option, as such a major change to "stable" versions (even if most users of the image probably won't be affected) is not acceptable.
  • Switch: One or a couple: The change is the biggest benefit for 5.5, since it would get rid of the generic linux package. But it would still be breaking someone's build. Also, having one version on OracleLinux and the rest on Debian will pretty much invert the "standardized" benefit :)
  • Switch 8.0: Safer, since as a dmr it is not considered production ready, but we don't get the benefit since we have smaller 8.0.1 packages for deb as well.
  • Offer both: Best solution from user perspective, but it's already annoying and risky having to maintain three redundant copies of the Dockerfile and entrypoint script. Could we generate the files from a common source in some way?

The last option at least sounds best to me, but only if it's possible to have those files generated in some way, or if we could find a fairly clean way to have one script file handle all of them and just keep the copies fully in sync.

@tianon
@yosifkit
What are your thoughts on this?

@tianon
Copy link
Member

tianon commented Apr 28, 2017

Interesting thoughts -- if you (Oracle) are more willing/able to support MySQL on Oracle Linux, and would rather not support the Debian variants anymore, IMO switching 8.0 over outright is a no-brainer, regardless of anything else we decide to do. 😄

Regarding templates, we often use templates (postgres is one of our oldest examples: https://github.com/docker-library/postgres), and just recently switched golang to use templates too (https://github.com/docker-library/golang), but sometimes we go the other way (especially if we get into a situation where different versions have different needs, like we have here with 5.5 vs 5.6+5.7 vs 8.0).

So, adding Oracle Linux variants is fine if you want to commit to the added maintenance -- we're going to defer a lot to your decision here, we're still here just to support you. 😄

(We generally are very strongly against adding various "distro variants" just because, but I think this is a really strong case for an exception to that, given that MySQL on Oracle Linux is more "strongly supported" by upstream. 👍)

@geshan
Copy link

geshan commented May 26, 2017

wouldn't it be a great idea to use alpine as a base image given its just 5 MB?

@florianrusch
Copy link

florianrusch commented Jul 7, 2017

@geshan take a look into this issue: #179 ;-)

@ltangvald
Copy link
Collaborator Author

We have a working template system for the upstream images which will be released soon. It's pretty ugly with the sed commands, but it's not complex. I'm not sure if it would be possible to use a better scripting system, i.e. python, with the way the images are updated?

As mentioned, the OracleLinux images are more uniform since we build docker-specific rpm packages, but the only really big diff in the official images is in the 5.5 Dockerfile, since it uses the generic linux packages. So if we manage to get everything else into templates that should still be a pretty big win maintenance-wise.

We can discuss it more once our updates are released.

@ltangvald
Copy link
Collaborator Author

https://github.com/mysql/mysql-docker has been rewritten with a simple template system now (same system is used in the mysql-cluster branch as well)

@tianon
Copy link
Member

tianon commented Jul 31, 2017 via email

@wglambert wglambert added the Request Request for image modification or feature label Apr 25, 2018
@ltangvald
Copy link
Collaborator Author

@tianon
@yosifkit
https://github.com/ltangvald/mysql-1/commits/rpmbase has a first version of a Dockerfile for Oraclelinux

This seems to work pretty well with the current entrypoint script (so I've also renamed .template.Debian to .template.entrypoint since that is actually platform-independent), but there are some practical issues to work out I would welcome some suggestions for:

  • rpm-based platforms use "x86_64" and "aarch64" instead of "amd64" and "arm64", so need some form of mapping in update.sh or the Dockerfile itself. Currently I've just hardcoded amd64 for the gosu release, but since part of the point of this is to add arm64 image, it needs resolving.
  • Currently update.sh loops through all directories and treats them as major versions (5.6/, 5.7/, etc.), so can't just add a 8.0-ol directory without breaking it. Maybe just change it to a variable listing the versions?
  • We only support arm64 for 8.0. How are multi-arch images generally built?

@yosifkit
Copy link
Member

When supporting multiple OS distributions, we've often converted our repos to do something like [version]/[os variant]/, so here we could do a 8.0/debian and 8.0/oracle (or oraclelinux). Just like the version folder, the existence of the specific os folder would control whether that Dockerfile gets generated (I'll look to add a template Dockerfile for Debian).

Here is an similar layout in ghost.

I don't think we should have multiple template folders (.template.OracleLinux, .template.entrypoint, .template.Debian, etc), since we can just put it all in one folder (in most of our repos, we just drop them all at the root since it is only a few files). So I think a single .templates might make the most sense here with a Dockerfile-debian and Dockerfile-oracle along with the docker-entrypoint.sh.

As for as the new Oracle Dockerfile:

  • it will need an explicit version like line 49 in Debian (that update.sh can bump):
    ENV MYSQL_VERSION 8.0.18-1debian9
  • it should install gosu before mysql to maximize caching (like the debian Dockerfile)
  • we may want to have all images add the mysql user with an explicit user ID to ensure better interoperability (like postgres does)
  • we've found that the most reliable way to detect arch is dpkg --print-architecture (since uname is the kernel arch and not necessarily the libc arch)

We only support arm64 for 8.0. How are multi-arch images generally built?

Here is our FAQ on building: https://github.com/docker-library/faq/#how-are-images-built-especially-multiarch. To control which arches are built it is just a field in the library/mysql file in official-images like ghost with the default being amd64 (we'll need to add this in generate-stackbrew-library.sh). Is that what you were looking for?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request Request for image modification or feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants