Docker is become an incredibly prevalent tool in the development and
operations realms in recent months. Its combination of developer friendly
configuration and simple operational management make it a very attractive
prospect for companies and teams looking to adopt CI and CD practices.
In most cases, you’ll see Docker used to deploy applications in much the
same way as a zip file or virtual machine image. This is certainly the
most common use case for Docker, but by no means the extent of its
functionality.
In this post I’m going to discuss some of the more interesting problems
we’ve used Docker to solve and why it serves as a great solution to them.
Aurelia is a modern web application framework in the spirit of Angular,
with an exceptionally concise and accessible developer experience and
standards compliant implementation. It is hands down my favorite web
framework right now and one I’d strongly recommend for most projects.
One of Aurelia’s greatest claims to fame is the incredible productivity
you can achieve, enabling you to build a full web application in just
days, if not hours.
When building the application becomes that fast, spending a day putting
together your deployment pipelines to roll out your application becomes
incredibly wasteful, so how can we avoid that?
Well, Docker offers us a great way to deploy and manage the life-cycle
of production applications. It enables us to deploy almost anywhere, with
minimal additional effort and in a highly reproducible fashion.
In this post I’ll go over the process of Dockerizing an existing Aurelia
web application built with WebPack, however the same process applies to
those built using SystemJS.
Traefik is an application load balancer written in Go and designed to simplify
the task of serving HTTP(S) services whose configuration changes on the fly. Traefik v1.1.0
was recently released with support for Docker Swarm and it works excellently.
In this post, we’ll go through how one sets up their Swarm cluster to automatically expose
its services through Traefik.
Docker Swarm is one of those interesting new technologies which has succeeded in shaking up
people’s preconceptions around what it means to run a scaleable cluster. In an environment
where everyone seems to be building a cluster orchestrator, including some big names like
Google’s Kubernetes, HashiCorp’s Nomad and Mesosphere’s Marathon;
Swarm has managed to burst through as one of the most attractive orchestration frameworks out
there.
As a result of all this hype, it can be difficult to make a decision around whether Swarm is
the right tool to use. As someone who has had extensive experience with running Swarm,
Kubernetes, DC/OS (Marathon) and Rancher in production
environments, I’ll try to give you an unbiased view on the reasons you’d choose Swarm
and some of the gotchas to be aware of.
