An Ensemble Core with Docker - Solving a Real Pain in the PaaS

Editor's Notes

• #2: My objective objective is to convince you that running Docker on CoreOS is a real possibility, but it requires some extra tooling First I will cover about 20 slides to go over the problem and some details I assume that you’ve played with docker a little bit and know what CoreOS provides. I will cover what I have built and how it solves the problems The solution is simple, does not require any extra services to run and is built on top of existing tools
• #3: The problem is that all these tools have sprung up and it’s not clear how to use them together. We’re in the early days of the wild-wild-west as it relates to docker. What we’re really doing is observing a transformation in how services are shipped. Before there were distributions like Redhat or Ubuntu, there were no good ways to make software work together. Just like there used to be no good way to make software work together on the same OS, now there is no good way to make services work together on the same cloud.
• #4: By overkill, I mean overkill for smaller deployments and add a level of complexity not necessary.
• #5: Services need to be aware of each other. Even a simple blog has multiple moving pieces. They need a way to do service discovery. Many ways of doing it. Dynamic DNS is one easy way.
• #6: If only things were that easy. LAMP is dead. Long live the LAMP stack. Open Source has exploded & that’s a good thing. But now we gotta find out how to get this new fangled stack to run that defies abbreviation. Today we have to worry about getting all these components to play nicely with each other.
• #7: Exposing ports is evil. They are a scarce commodity. There should only be 2 ports exposed - 80 and 443. I hate it when I see a charming image only to disappoint me by bundling supervisor and voiding the one-process-per-container model. This masks any underlying problems Prevents systemd from using the rules that it’s been configured to work with
• #8: No good way to see what is running. Lots of commands but not stitched together. Docker shows you all the services that are running. This is unmanageable when you have hundreds or thousands of services. Docker won’t ensure your services are always running It’s hard to visualize how services are composed and related to each other. There needs to be a way to look just at how one group of services is performing You can link containers together, but right now that doesn’t work across hosts.
• #9: It helps us schedule services ala systemd, but there a lot of gotchas You can’t easily tell if you forgot to start a service You can’t see if a service has been orphaned Order matters - You have to remember the order in which to start services or you reach a dead lock. Try doing that with hundreds of services. You can’t easily restart services when making changes to unit files without running a half dozen commands. You can’t easily tell at a glance what is failed vs dead You cannot drop to shell inside of a container to inspect what’s going on Does not handle journaling of global services
• #10: Units require a lot of configuration Everything highlighted might need to change between different stages or environments. Leaves a lot of room for error. There’s a lot of redundancy Unit files are easily resuable for different images. It doesn’t make sense to hardcode the docker image. Docker names need to be unique.
• #12: These are the missing pieces needed to tie everything together. Fleet only does scheduling. Scheduling is handled by systemd. Something needs to handle orchestration and the composition of microservices Docker as it stands today, is only really good at running containers not managing relationships between containers..
• #13: Can’t there be a way to stitch all the tools available today to get a working containerized environment without going overkill with Apache Mesos and Kubernetes?
• #14: ...all this without sacrificing good architecture & design. All this without having to invest all the time and effort to get the pieces to play together. That would be pretty cool, right? Keep it simple, stupid.
• #17: Here are just some of the things I want to call out that it supports. Convention over configuration by design; seek to decrease the number of decisions that you need to make, gaining simplicity, but not necessarily losing flexibility due to it’s empirical design.
• #18: I am now going to go over what can be done. I’m might brush over it a little bit quickly because I want to get to the demo. Everything in green are awesome extensions that implement original functionality. Where applicable, they are cluster-aware.
• #20: Templates define imperative configurations.
• #22: DNS Search also supported. So it could just say “mysql” and it will search the local domain
• #23: Order matters! Just define the units in the order they need to be instantiated and it will respected
• #24: Just specify how many of them you want to create.
• #25: ping vpn.central.cloudposse.local ensemble --config ~/Dev/cluster-configs/deployment.yml build ensemble --config ~/Dev/cluster-configs/deployment.yml build ib ensemble --config ~/Dev/cluster-configs/deployment.yml build ib web_mysql ensemble --config ~/Dev/cluster-configs/deployment.yml status ib ensemble --config ~/Dev/cluster-configs/deployment.yml stats ib