Illumina Innovates with Rancher and Kubernetes
In my prior posts, I’ve written about how to ensure a highly resilient workloads using Docker, Rancher, and various open source tools. For this post, I will build on this prior knowledge, and to setup an AWS infrastructure for Rancher with some commonly used tools. If you check out the repository here, you should be able to follow along and setup the same infrastructure. The final output of our AWS infrastructure will look like the following picture: In case you missed the prior posts, they’re available on the Rancher blog and cover some reliability talking points.
So last week I finally got out from my “tech” comfort zone, and tried to set up a Node.js application which uses a MongoDB database, and to add an extra layer of fun I used Rancher to set up the whole application stack using Docker containers.
I designed a small application with Node, its only function is to calculate the number of hits on the website, you can find the code at Github
Attention, Ansible users! We’ve released the first version of our Ansible playbooks for Rancher. Ansible is a configuration management system that allows you to write instruction manuals it uses to manage local and remote systems. These playbooks give full control over the installation and configuration of Rancher server and agent nodes, with features that include:
Static inventory Dynamic inventory via EC2 tags Detection of multiple servers and automatic configuration of HA Support for local, bind-mount, and external databases Optional, local HAProxy with SSL termination for single-server deployments Ansible Vault for secure storage of secrets This first release is for Ubuntu and Debian, and it targets EC2 as a provider.
John Patterson (@cantrobot) and Chris Lunsford run This End Out, an operations and infrastructure services company. You can find them online at https://www.thisendout.com *and follow them on twitter @thisendout. * Update: All four parts of the series are now live: Part 1: Getting started with CI/CD and Docker Part 2: Moving to Compose blueprints Part 3: Adding Rancher for OrchestrationPart 4: Completing the Cycle with Service Discovery In part one of our series, we left off with constructing a rudimentary build and deployment pipeline.
RancherOS eliminates any unnecessary libraries and services, resulting in a footprint three times smaller than that of other container operating systems.
RancherOS v0.8.0 is now available! This release has taken a bit more time than prior versions, as we’ve been laying more groundwork to allow us to do much faster updates, and to release more often.
Release Highlights Using the Linux 4.9.9 mainline kernel Using the mainline stable Linux kernel should allow us to give container users access to new features faster - and will mean that RancherOS will have a simpler debug and update path for other software too.
Note: this is Part 4 in a series on building highly resilient workloads. Parts 1, 2, and 3 are available already online. In Part 4 of this series on running resilient workloads with Docker and Rancher, we take a look at service updates. Generally, service updates are where the risk of downtime is the highest. It doesn’t hurt to have a grasp of how deployments work in Rancher and the options available within.
Visit us to learn more about using Ansible with Docker to deploy a Wordpress service on Rancher. For more tutorials and to request a demo, visit Rancher today.
Today, Chef announced the release of Habitat, a new approach to automate applications. Habitat shifts the focus of application management and configuration from the infrastructure to the application itself. In a nutshell, it allows users to create packages that encapsulate the application logic itself, runtime dependencies, and configuration. These packages can then auto-update accordingly to policies set by your organization. In this article, I will show you how to leverage the runtime configuration and service member discovery capabilities of Habitat to build a Rancher Catalog template.
With the recent \“container revolution,\” a seemingly new idea became popular: immutable infrastructure. In fact, it wasn’t particularly new, nor did it specifically require containers. However, it was through containers that it became more practical, understandable, and got the attention of many in the industry. So, what is immutable infrastructure? I’ll attempt to define it as the practice of making infrastructure changes only in production by replacing components instead of modifying them.