There is now a production docker container of foreman building automatically (on every merge to core) at https://quay.io/repository/foreman/foreman and a docker-compose ready to use production environment you can deploy by:
docker-compose run app bundle exec rake db:create db:migrate docker-compose run app bundle exec rake db:seed docker-compose up
and login to http://localhost:3000 (note that the password was printed during db:seed above)
if you like to upgrade your environment
docker-compose pull docker-compose run app bundle exec rake db:migrate db:seed docker-compose up
ATM if you would like to add additional plugins you should rebuild the image yourself (details below).
Please don’t use it for real production environments (yet)
Recently I’ve been working of adding dockerfile to foreman core, that an image can be built easily directly from source.
The aim of this change was not to introduce a new way for users to install Foreman via containers (even if its possible) rather more as a development (or developers) tool.
The motivation I had in mind was:
- reliable / continues builds based on git / source
- Build production environments from PR so people can easily test, reproduce bugs etc
- Simple enough that everyone can just take it out for a quick spin
- Being able to add E2E testing on top
- Allow users to see latest features, translators to see the current state of strings etc.
Currently, there is a docker-compose file that enable production environment, in order to use it you need to ensure you have both docker and docker-compose installed locally.
Out of the box, it runs:
- MySQL server (can be easily swapped to pg, I just happened to use my local DB for testing)
- A single rails puma process
- Dynflow worker.
If you look into the content of the file, its pretty simple to add additional services if needed.
Additionally, this image contains a report of the webpack build that can be found at
http://localhost:3000/webpack/report.html, this is useful to see how the assets are complied and used within the application.
It supports the various languages (so translators and developers can see the current language state) and include hammer cached API binding that hammer tests can be done against it as well.
This by no means a complete work, nor I’m suggesting we should invest a lot into this before it proof itself useful to us.
How to build your own image
- Using quay.io (or similar service), I’ve found its easiest simply to configure quay.io to build the images for me, the workflow is simple enough (e.g. on every git push to my repo an image will be built) and it doesn’t slow down my machine while building it (it takes about 7-8 minutes or so).
- Building locally - The easiest is simply to run
docker-compose build app
docker build . -t mytag
if you have any plugins configured in your
bundler.d/Gemfile.local.rbit will pick them up and include them in your generated container, you would then might need to change the line pointing to the container image to point to the image you just created.
- Note that you need a recent version of docker (e.g. from the last couple of years, not what ships in fedora by default) to build it, you might consider using podman to build it instead.
If you happen to have gem in a local checkout - e.g.
gem 'foreman_memcache', path: '../foreman_memcache'
and don’t want to mess up with paths, I would suggest to create directory called “dev” or something under your foreman directory, so in your bundle file you have something like
gem 'foreman_memcache', path: 'dev/foreman_memcache'
I personally just did
mkdir dev cd dev ln -s ../../foreman_memcache . cd ..
and then, let tar follow symlinks, e.g.
tar -chf - --exclude-from=.dockerignore | docker build -
I did not verify that all features work, I’m pretty sure stuff breaks, a list of stuff I’m aware of are:
- Logging doesn’t work to STDOUT (not sure why)
- audit logs contains references to the container hostname (and many times they swap over because of multiple containers setting the value)
- No way to pass settings via environment variables (to common way to solve configuration with containers).
- investigate base image should we use, maybe UBI - I did do initially a POC here but felt it was too much to do in one PR, maybe better use ubi-minimal…
- move the base image to a foreman-container-base, so builds could be a bit faster to build
- E2E testing, perhaps similar to the suggestion by @amirfefer
- Add foreman-proxy
- Add LB / SSL Termination
- Enable more specific services (such as the one needed for Katello)
I would be happy to see continuation of this for developer environments, perhaps similar to
Thanks for reading…