It’s 8:00 PM. I just deployed to production, but nothing’s working. Oh, wait. the production Kinesis stream doesn’t exist, because the CloudFormation template for production wasn’t updated. Okay, fix that. 9:00 PM. Redeploy. Still broken. Oh, wait. The production config file wasn’t updated to use the new database. Okay, fix that. Finally, it works, and it’s time to go home. Read more
Recently, I moved to New York City. As a new resident, I decided to take part in the NYC DeveloperWeek hackathon, where our team won the NetApp challenge. In this post, I’ll walk through the product we put together, and share how we built a CI/CD pipeline for quick, iterative product development under tight constraints.
The Problem: Have you ever lived or worked in a building where it’s a pain to configure the buzzer to forward to multiple roommates or coworkers? Imagine that a friend arrives and buzzes your number, which is set to forward to your roommate who is visiting South Africa, and has no cell service. If you’re running late, your friend is just stuck outside.
The Product: We built a PBX-style application that integrations with Zang, and forwards a buzzer to multiple numbers, and even allows your friend to use a PIN on his phone to gain entry.
The constraint: For the hackathon, we had to use hardware that had already been setup and allocated.
Building our Hackathon CI/CD Pipeline
Our newly-updated eBook walks you through incorporating containers into your CI/CD pipeline. Download today!
For the competition, we knew that we wanted our builds scalable from the start, and that each deployment would snapshot our entire data environment pre-deployment using NetApp ONTAP (a sponsor of the Hackathon, and a really nice group of folks); if any deployment had an issue, we could simply and quickly roll back.
Fortunately, I am a firm believer in building stateless, Docker container-ready, rebuildable architecture; I can’t go back to the world that existed before: no real CI/CD, lots of SSH-ing into other systems, or SCP-ing data from one place to another. Thankfully, today we have tools and strategies that can help us.
When deploying applications in the container world, one of the less obvious points is how to make the application available to the external world, outside of the container cluster. One option is to use the host port, which basically maps one port of the host to the container port where the application is exposed. While this option is fine for local development, it is not viable in a real cluster with many applications deployed. One solution is to use an HTTP proxy/load balancer. This container will be exposed using standard HTTP/HTTPS ports on the host, and will route traffic to the application running as a container.
In this post, we will setup Traefik as an HTTP proxy / load balancer for web services running in a Rancher Cattle setup. Traefik will dynamically update its configuration using the Rancher API. An SSL wildcard cert will be used. The (nice) Let’s Encrypt ACME feature Traefik is offering will not be used here. We will make use of Rancher secret feature. If you plan to use Traefik with Let’s Encrypt SSL certs, I encourage you to use the Traefik stack available in Rancher Community Catalog.
This week, the Moby Project was introduced with the idea of componentizing Docker into a series of assemblies. At DockerCon, a neat demo was done using the moby tool to assemble various components into customized Linux operating system images. While very cool, this seemed to have confused people – we’d like to provide some more background and explanation about the Moby Project and how it affects Rancher, RancherOS, and our users.
Some background on the Moby Project
The transition to the Moby Project actually started a couple of months ago, with a discussion among the Docker Project maintainers, about the dual nature of Docker as both a product and a project. This dual nature served Docker (the project and the company) well in the beginning, but at the end of the day, Docker, Inc. must make hard decisions about what their product should and will be. As a group of maintainers, we agreed that the product and project should be split. Read more
We’re winding down for the year, but you’ll still be able to check out Rancher in a few places, live and in real-time. We always look forward to meeting users whenever we can, and hearing from you only helps make us better.
Dec 14, Online Meetup: Deep Dive on Rancher 1.2 This month, we shipped the latest version of Rancher, which brings in a massive set of improvements. See the newest support for container storage and networking, and how we wrap them into templates for container-ready environments.
Dec 20, Lyon, FR: Introduction to Rancher. Rachid Zarouali will be providing an introduction to the Rancher container management platform at the Lyon Docker meetup, along with a short overview of adjacent technologies like Prometheus and Grafana.
We’ve been really fortunate at Rancher to have an enthusiastic community of users around the world, and we always looking forward to seeing and meeting our users in person. Here’s a few places Rancher will be in November. Please come say hi (and by the way, you can always keep track of where we’re headed at rancher.com/events)!