-
Notifications
You must be signed in to change notification settings - Fork 54
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
Add docker support for experimentation #81
Conversation
00b2556
to
14425d1
Compare
This is awesome @logicminds! I only have one comment here, around content organization. Currently, all of the new Docker content is located in My instinct is to put this content inside the spec folder, and give it a name that quickly communicates what it's for. Maybe What do you think? |
I don't think the spec folder is the right place either. Most dockerfiles are in the root of the repo and nesting under spec would confuse people with tests. I thought about under documentation or maybe even a dockerfiles folder in the root of the repo. |
Re: Dockerfiles in the root of the repo, is that consistent for all uses of Dockerfiles, including use cases where the purpose of the Dockerfile is to enable tests? Most uses of Dockerfiles I've seen are for actually containerizing an app of some kind, which we aren't doing. We're just using Docker to enable a testing use case. Right? |
Maybe part of what I'm confused about is that even in the PR as-is, the Dockerfile isn't in the repo root. It's still under |
I don't intend to add the Dockerfile to the root because it does not represent the peadm. Instead it is just a systemd enabled image required in order to run PE in a container. I am going to move this to the spec folder since the Bolt project does the same thing and it is better to be consistent. |
* Previously working on this module required a buildout of a puppet infrastructure with VMs or cloud providers. Which can sometimes be costly or take hours to deploy. This commit uses containers and docker-compose to produce sample environments for each architecuture in order to perform rapid prototyping or test the functionality of this module and the puppet infra command. The architectures supported in this command are: * standard, stadard-ha * large, large-ha * extra-large, extra-large-ha While there are many other possiblites and combinations of amount of servers and containers these are the current choices. For more information please see documention/docker_examples.md
Thanks @logicminds!! |
This adds docker support to allow quick and dirty test environments when playing with the peadm module or PE HA commands. It will allow you to provision entire HA stacks as defined by the documentation without using vagrant or deploying to the cloud. The provision time varies from 10-20 minutes depending size and resources available.
Prior to this there was not a quick way of playing with HA on your laptop. Users will be able to spin up standard and large (with and without HA) on their laptops (when equipped with 16GB memory and linux). And if the user has 24GB+ they can spin up XL and XL-HA.
The goal of this feature is to allow users the ability to test out these tasks and plans before going to production. Additionally, peadm development can also be tested here since all code is mounted as a volume in the container.
In order for this PR to be merged it has a few dependent PRs #80 , #79 , #78. These PRs were opened after finding issues developing the docker support. Once the other PRs are merged I will rebase and bring the other newer commits into this branch. Until this please give this branch a try and let me know where more documentation is required or issues that you run into.