@ohadlevy: Are you also planning on adding a Dockerfile to smart-proxy?
I’ve been toying with the idea of adding configuration via ENV variables to smart-proxy.
Massive +1 to this, I’m going to look into using it for tests with foreman-ansible-modules
1 Like
I didnt, but perhaps its too easy :- ) something like https://github.com/shlomizadok/foreman-docker-compose/blob/master/proxy/Dockerfile
I’ve also been toying with a proof of concept. For a demo I decided to rewrite the proxy from scratch in Python (just the Puppet module for now). The framework I’m using defaults to reading env vars. It does type casting since env vars are strings. It’s going to be a challenge to do that right in the current proxy which doesn’t really know about data types and trusts it to come from YAML. That may also be an issue in the Foreman configuration but probably easier since it already has a model around settings.
@TimoGoebel (and others present next week): let’s talk about this next week and see if we can come up with a plan/proposal
1 Like
may I ask why? just wondering what kind of issues are you having with the current proxy code base?
I want to demonstrate the interaction with Foreman and that it’s really straight forward. The codebase is big and complicated so it’s hard to show a very minimal version. In about 100 lines I could implement a functional proxy including an implementation of the Puppet feature.
It was also a lot of fun to teach myself modern Python web frameworks and I always teach myself by implementing something semi-serious. Automatically generating an openapi schema was also an interesting experiment.
While doing so, I even found a bug in the Smart Proxy Puppet module for which I still need to open an issue. When a Puppet parameter defaults to false, it’s represented as a string instead of a boolean (where true is a boolean).
OK, I did an initial POC at https://github.com/ohadlevy/smart-proxy/commit/3caf0f1a9ffcc16d46514d0d26f4121156ed20e4 - if you like it, please continue based on it, the main part that breaks is the settings.
Wow! Congratulations! Great job! 
This looks like some serious hard work to have that gotten to work. Especially the Dockerfile.
While I’ve not yet reviewed everything I’ve started to note down a few thoughts somewhere else. (I’m not quoting it here, it would be unnecessary distraction.)
up2date, “official” documentation can now be found at https://github.com/theforeman/foreman/blob/develop/developer_docs/containers.asciidoc thanks for everyone who helped to review.
2 Likes
I’m working on a project for Foreman and Puppet, but would rather contribute to this instead of working solo. Do you have a parent issue (epic) for this? For starters, what integration testing framework are you planning on using? I’m using Fabric8’s docker-maven-plugin which seems like it would fit nicely into Redhat’s stack, but maybe you want to use something more Ruby-ish? Maybe a good start would be to move in some testing and go from there? Or maybe you already have a roadmap staked out?
We’re running Foreman + Puppet in production (I know that you’re offering
it as a development option) and it would be nice to contribute. I guess my
convoluted question is simply: is there an issue, epic, roadmap that we
could look at to grab issues, bugs, and feature requests so that we could
help with this? We’re interested especially in contributing test cases (I
don’t see any docker tests in the master branch) and maybe some smart proxy
images if you’re accepting them.
I would guess the parent “epic” (we use redmine which doesn’t have a concept of epics) is at Refactor #18732: Make Foreman Containerizable - Foreman.
Feel free to add issues and link them to that one? it would be good to understand your plans, and of course, patches are welcomed 
Thanks! That’s exactly what I’m looking for. I’ll take a look at what’s
already on there and see if I can start making some merge requests.
We would like to help make foreman production ready and robust.
Would you be OK with some syntax and unit testing to start with? Hadolint.
Shellchecker. Some kind of scanner… maybe Trivy. Any other ideas?
Do you have any ideas around integration testing? Or maybe you’re simply
thinking about overlaying your current integration tests?
Den tis 16 juli 2019 08:41Ohad Levy via TheForeman <
noreply@community.theforeman.org> skrev:
Hello,
I have few ideas…
Would be superuseful to handle:
bundle exec rake db:create db:migrate
and
bundle exec rake db:seed
in https://github.com/theforeman/foreman/blob/develop/entrypoint.sh
Dont know if exist something that will get database info, if its migrated and seeded… ( it may check if these steps are neccessary to run )
Another thing may be plugin installation. I am suggesting something like
docker run -d --name foreman \
-e GEMS_TO_INSTALL="fog-proxmox foreman_fog_proxmox foreman_ansible"
quay.io/foreman/foreman:1.23-stable
This can be also handled in entrypoint.sh like:
for i in $GEMS_TO_INSTALL; do echo "$i" >> bundler.d/container.rb ; done && /usr/bin/bundle install
Last thing that comes to my mind is bundle exec rake permissions:reset password=change,
this should not be handled by entrytpoint.sh
Password is stored in database, or somewhere on filesystem?
If filesystem, then can docker VOLUME help , if in database, permissions:reset password=change will everytime reset the password -> if new instance of foreman will connect to old database, which is not necessary.
Any thoughts on that?
I was initially keeping it out of the entrypoint thinking this wont make a lot of sense if someone is running many foreman instances (e.g. on a busy kubernetes env) where pods/containers will stop and start, it will reduce the load time for the application.
in my kuberenetes/openshift environment, I simply have a job that does that, having said that, I do believe that if we plan to continue this path, we would need to make some adjustments in how we migrate db etc
overall, if its a pain point, not hard to include it in the entrypoint for now I assume…?
do you mean in order to avoid running it all the time? both migrate and seed will not do anything on a running system, so its harmless (just takes longer to start).
with this I disagree a bit, for two main reasons:
- it will download bits from the internet on run time, meaning every time you would start the container.
- I believe that different plugin combinations are different images, therefore if you want to add a new plugin, simply rebuild the image (as described at https://github.com/theforeman/foreman/blob/develop/developer_docs/containers.asciidoc#building-your-own-image)
password is not on the filesystem, it encrypted inside the DB. the default would just randomly generate a new password, but instead of looking in the seed output, i thought making it easily changeable via the CLI/env var would be good enough…?
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.
For an example, you can see PostgreSQL’s image at https://github.com/docker-library/postgres/blob/master/docker-entrypoint.sh. They use the directory /docker-entrypoint-initdb.d/* so that users can toss in .sql scripts as needed. For another example, the maintainers at Puppet also use this technique: https://github.com/puppetlabs/puppetserver/blob/master/docker/puppetserver-standalone/docker-entrypoint.sh.
1 Like
would you be willing to send a PR to implement this? thanks!
just wondering, did you end up using it? 
how are you running it? plain docker/systemd or kubernetes?
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.
1 Like