I finally got a chance to sit down with this and see if we can’t merge this image in to our production Foreman instance. First of all, well done! I did though run into exactly the same issue as @lukasmrtvy regarding database rake tasks.
For me, it would be better to have either booleans in the entrypoint.sh script, such as [ -z DB_SEED], so that we can run these when needed, or even better, in my mind, provide an entrypoint.d directory that gets parsed before running entrypoint.sh. This gives everyone the flexibility to add their own startup stuff without cluttering up the image with different use cases. This would allow people to install gems, seed the database, run different rake tasks… whatever.
I’ll take care of the PR. Since this is my first PR for Foreman, do I need
to raise an issue and reference it? Or will referencing #18732 suffice?
We’re using a docker-compose file for the time being while we get ready to
move over to Kubernetes, hopefully by next year. We’re governmental
organization running a bit over 400+ nodes, using Puppet + Foreman as the
ENC. Right now, I’m trying to refactor my repository so that’s in line with
yours. You can view the work at https://github.com/luksi1/docker-foreman.
The issue in which I’m running the refactor is branch “issue-26”.
Hopefully, this branch will get merged shortly and we will be able to start
contributing to the project with more and more meaningful feedback!
As a side note, where do you want the documentation for this? I haven’t
seen any Docker or docker-compose information in the docs, but maybe I’m
missing something. In case there isn’t any, do you want the documentation
in the manual? In a markdown file on the site in GitHub? I do personally
think docker-compose is a nice way to on-board people with minimal set-up
so they can try Foreman out and see Foreman’s value quickly before deciding
whether or not to move forward. I would be more than happy to do this, I
just need to know if I’m sending a PR to the project or if I need to send
over the documentation in another form. Let me know what you think.
Just as a heads-up, some recent (or not so recent) changes in the code now make it significantly harder to run TheForman easily via “docker-compose up”:
There don’t seem to be any instructions on how to get started with the Docker Compose setup (at least not in the obvious places, the README and the doveloper documentation).
For some reason, even after running database migrations and seeding (via docker-compose exec app ... and restarting the entire stack) the Rails application doesn’t respond at http://localhost:3000/. Strange.
Sorry for cross posting but this thread seems like the most active. I also posted under ‘Community’
Looking to see if Foreman in Docker is nearing production ready. We have a older version 1.16.0 that we are looking at fork lifting to 2.0 now. Its managed by a bunch of custom Ansible goop that I would like to switch out for just running docker.
Great Work! I have a dumb question but where do I find puppet after this is up? I’m trying to test it with a manifest and I cant find the puppetlabs directory
The Dockerfile doesn’t include any plugins, and since Puppet is a plugin, it’s not included. The recommended way is include plugins is to add files to bundler.d:
The Foreman uses its configured client certificates to connect to the Smart Proxy. Then Smart Proxy uses its configured client certificates to connect to Puppetserver. Puppetserver (via the puppet-puppetserver_foreman scripts) connects back to Foreman, but using the identify of the Smart Proxy.
We’ve talked about the Puppetserver talking to Smart Proxy, but never finished that. GitHub - theforeman/smart_proxy_reports was a partial solution (still left out the ENC and fact uploads), but has since been abandoned due to a lack of time.
You could opt for a classical Smart Proxy installation in the short term and first focus on getting the Foreman part containerized.
No, I think that’s pretty much what should do. Implementation wise you could consider something like:
RUN echo "gem 'foreman_puppet', '~> 5.1', '>= 5.1.1'" > bundler.d/puppet.rb
Entirely untested, but it may make layering easier by keeping everything inside a single file. The group is technically not needed, so that makes it even easier.