We are currently operating a service oriented architecture that is ‘dockerized’ with both host and containers running CentOS 7 when deployed straight on top of ec2 instances. We also have a deployment pipline with beanstalk + homegrown scripts. I imagine our position/maturity is similar to a lot of SMEs, we have aspirations of being on top of new technologies/practices but are some where in between old school and new school:
| Old School | New School |
|---|---|
| IT and Dev separate | Devops (Ops and Devs have the same goals and responsibilities) |
| Monolithic/Large services | Microservices |
| Big Releases | Continuous Deployment |
| Some Automation | Almost total automation with self-service |
| Static scaling | Dynamic scaling |
| Config Management | Image management (with immutable deployments) |
| IT staff have a high baseline work | IT staff have low baseline work, more room for initiatives |
This is not about which end of this incomplete spectrum is better… we have decided that for our place in the world, moving further the left is desirable. I know there are a lot of experienced IT operators that take this view:
Why CoreOS for Docker Hosts?
CoreOS: A lightweight Linux operating system designed for clustered deployments providing automation, security, and scalability for your most critical applications – https://coreos.com/why/
Our application and supporting services run in docker, there should not be any dependencies on the host operating system (apart from the docker engine and storage mounts).
Some questions I ask myself now:
- Why do I need to monitor for and stage deployments of updates?
- Why am I managing packages on a host OS that could be immutable (like CoreOS is, kind of)?
- Why am I managing what should be homogeneous machines with puppet?
- Why am I nursing host machines back to health when things go wrong (instead of blowing them away and redeploying)?
- Why do I need to monitor SE Linux events?
I want a Docker Host OS that is/has:
- Smaller, Stricter, Homogeneous and Disposable
- Built in hosts and service clustering
- As little management as possible post deployment
CoreOS looks good for removing the first set of questions and sufficing the wants.
Why Kubernetes?
Kubernetes: “A platform for automating deployment, scaling, and operations of application containers across clusters of hosts” – http://kubernetes.io/docs/whatisk8s/
Some questions I ask myself now:
- Should my deployment, monitoring and scaling completely separate or be a platform?
- Why do I (IT ops) still need to be around for prod deployments (no automatic success criteria for staged deploys and not automatic rollback)?
- Why are our deployment scripts so complex and non-portable
- Do I want a scaling solution outside of AWS Auto-Scaling groups?
I want a tool/platform to:
- Streamline and rationalise our complex deployment process
- Make monitoring, scaling and deployment more manageable without our lines of homebaked scripts
- Generally make our monitoring, scaling and deployment more able to meet changing requirements
Kubernetes looks good for removing the first set of questions and sufficing the wants.
Next steps
- Create a CoreOS cluster
- Install Kubernetes on the cluster
- Deploy an application via Kubernetes
- Assess if CoreOS and Kubernetes take us in a direction we want to go