Hey list,
A while back I have created a Foreman docker-compose repo [1], that runs
Foreman under docker-compose, separated to several containers (Foreman /
Proxy / DB / HAproxy).
Recent contributions by Ohad and Sebastian [2] made it a cool playground to
run latest development / stable.
So, I wonder whether we should move this repository to under theforeman.org
on Github, or under forklift.
I'd love to hear your thoughts and to which umbrella shall we move this
repo.
> Hey list,
> A while back I have created a Foreman docker-compose repo [1], that runs
> Foreman under docker-compose, separated to several containers (Foreman /
> Proxy / DB / HAproxy).
> Recent contributions by Ohad and Sebastian [2] made it a cool playground
> to run latest development / stable.
> So, I wonder whether we should move this repository to under
> theforeman.org on Github, or under forklift.
>
I'd vote Forklift to center development, and provisioning resources but I'm
a bit biased We want to move Forklift to Foreman proper just need to
initiate it. I look forward to taking what you guy have put together and
adding in some work I have locally.
E
···
On Sun, Nov 6, 2016 at 7:48 AM, Shlomi Zadok wrote:
I’d love to hear your thoughts and to which umbrella shall we move this
repo.
>
> > Hey list,
> > A while back I have created a Foreman docker-compose repo [1], that runs
> > Foreman under docker-compose, separated to several containers (Foreman /
> > Proxy / DB / HAproxy).
> > Recent contributions by Ohad and Sebastian [2] made it a cool playground
> > to run latest development / stable.
> > So, I wonder whether we should move this repository to under
> > theforeman.org on Github, or under forklift.
> >
>
> I'd vote Forklift to center development, and provisioning resources but I'm
> a bit biased We want to move Forklift to Foreman proper just need to
> initiate it. I look forward to taking what you guy have put together and
> adding in some work I have locally.
I may have the same bias but I agree that merging it into forklift is
the best place.
···
On Tue, Nov 08, 2016 at 08:29:38PM -0500, Eric D Helms wrote:
> On Sun, Nov 6, 2016 at 7:48 AM, Shlomi Zadok wrote:
I’d love to hear your thoughts and to which umbrella shall we move this
repo.
If you still think merging the effort into forklift is the solution then let’s look into this again.
For what I understand the idea of forklift is based on VMs and Vagrant (aka “heavy-weight”). Foreman-docker-compose is an alternative approach using Docker. It would complement the offering of getting started quickly, which is nice. For both approaches it’s necessary that they stay aligned with the original code base (and documentation).
To help add some color, Forklift technology wise did originally start with Vagrant. However, the mission of Forklift has always been around building Foreman environments. Over the years, we’ve transitioned the project into using Ansible to allow building a Vagrant machine or a users own resource. We’ve also moved all of the Vagrant bits into their own directory as they are a vehicle for building but not the sole purpose of the repository. This is also why I started a containerization effort in Forklift as this fits the mission of the project. The effort there is focused on providing images for the ecosystem, and K8s/Openshift deployment tooling. It is my belief that the ecosystem is too complex for docker-compose and that we are better off spending our efforts making good, flexible images that are focused on running on K8s/Openshift to all learn that deployment style, reduce doubling up effort, and solidify that deployment model. I am happy to discuss how to make this easier to consume by users and developers.
After reading the README I understand that this is for non-production deployment (no mountpoint for PostgreSQL). For this reason I also prefer Forklift.
In the past I’ve used docker-compose for a development setup and I generally liked it. No idea how well it would work for a production setup and if you should even want that. Perhaps it’s possible to get a minikube development setup but I still don’t mind a docker-compose directory in forklift.
Maybe it helps to understand that Docker Compose is really no magic. It’s “just a Python script” that wires Docker containers together, based on a YAML description. It’s what you would do with Docker on the command line manually, wiring up containers, volumes and networking services. Technically, what is running underneath is plain Docker.
With tools like Kompose you can create a Kubernetes (aka OpenShift) configuration that makes the same or a very similar configuration run on a Kubernetes stack. Even simpler, you could run a Docker Compose configuration with Docker Swarm (though I must admit, I haven’t tried this yet).
While “in production” and “for development” are technically two different places, I believe it’s imperative to keep the two environments as similar as possible. There are still developers (and admins) that apply changes to systems running in production. This is dangerous and not the way we should do software in 2018.
That’s what the whole buzz of Foreman-Docker-Compose is about (or at least, what it means to me). We need to bring the two worlds together. It’s a DevOps world, we’re moving our Ops knowledge into the development process, and this has only advantages.
Apologies for being slow to respond here, I’d been playing with my Discourse notifications and missing some threads.
With the goal being to allow running everything from smaller Foreman only to multi-plugin based deployments for development and production I do not see the value of docker compose over using K8s/Openshift via minikube/shift. From my experience, docker compose does not handle complexity well. Further, we have to maintain two different deployment configurations and style – K8s and docker compose. That seems counter-intuitive to the idea where we want to achieve development environment being as close to production as possible. Therefore, its my opinion that we should not introduce docker compose but rather stick with working on K8s based environments and finding solutions to workflows there.
@ehelms Could you point me to the related Dockerfiles once again? I re-thought the topic and I feel we should have Docker images for the components of The Foreman on Docker Hub that are built automatically each time a new version comes out.
Wiring such images properly with a Kubernetes setup, and OpenShift setup (hack, even with Docker Compose!) should be feasible. If those images exist and we maintain an example “wiring setup”, wouldn’t that be useful?
The reason to move it out of the forklift was that in reality it didn’t share any code. Initially it made sense because we were using ansible-container and we could share playbooks/roles. After it was changed to Dockerfiles, there was no more overlap.
The new repo is over here. Note that it was never an official release goal, but we are trying to find out what kind of code changes we need to make Foreman and friends container friendly.
We want to move Forklift to Foreman proper just need to