Illumina Innovates with Rancher and Kubernetes
Ye Olde Worlde Back in older times, B.C. as in Before Cloud, to put a service live you had to:
Spend months figuring out how much hardware you needed Wait at least eight weeks for your hardware to arrive Allow another four weeks for installation Then, configure firewall ports Finally, add servers to config management and provision them All of this was in an organised company!
The Now The new norm is to use hosted instances.
Today, Amazon announced a managed Kubernetes service called Elastic Container Service for Kubernetes (EKS). This means that all three major cloud providers—AWS, Azure, and GCP—now offer managed Kubernetes services. This is great news for Kubernetes users. Even though users always have the option to stand up their own Kubernetes clusters, and new tools like Rancher Kubernetes Engine (RKE) make that process even easier, cloud-managed Kubernetes installations should be the best choice for the majority of Kubernetes users.
One of the hallmark features of Rancher 2.0 is its ability to consume Kubernetes clusters from anywhere. In this post, I’m going to walk you through using the popular kops tool to create and manage Kubernetes clusters on AWS and then bring them under Rancher 2.0 management. This walkthrough will help you create a non-HA Kubernetes cluster, though kops does support HA configurations. With this new cluster, we will run the Rancher 2.
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.
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.
In less than a week, over 24,000 developers, sysadmins, and engineers will arrive in Las Vegas to attend AWS re:Invent (Nov. 28 - Dec 2). If you’re headed to the conference, we look forward to seeing you there! We’ll be onsite previewing enhancements included in our upcoming Rancher v1.2 release:
Support for the latest versions of Kubernetes and Docker: As we’ve previously mentioned, we’re committed to supporting multiple container orchestration frameworks, and we’re eager to show off our latest support for Docker Native Orchestration and Kubernetes.
Rancher ships with two types of catalog items to deploy applications; Rancher certified catalog and community catalog, which enable the community to contribute to the reusable pre-built application stack templates. One of the recent interesting community catalog templates is the external load balancer for AWS Classic Elastic Load Balancer, which keeps an existing Load balancer updated with the EC2 instances on which Rancher services that have one or more exposed ports and specific label.
Introduction If you have been working with Docker for any length of time, you probably already know that shared volumes and data access across hosts is a tough problem. While the Docker ecosystem is maturing, implementing persistent storage across environments still seems to be a problem for most folks. Luckily, Rancher has been working on this problem and come up with a unique solution that addresses most of these issues.
Containers and orchestration frameworks like Rancher will soon allow every organization to have access to efficient cluster management. This brave new world frees operations from managing application configuration and allows development to focus on writing code; containers abstract complex dependency requirements, which enables ops to deploy immutable containerized applications and allows devs a consistent runtime for their code. If the benefits are so clear, then why do companies with existing infrastructure practices not switch?
Visit Rancher for an overview of setting up and using Amazon's container registry service, plus a comparison to other hosted Docker repositories.
*Quentin Hamard is one of the founders of Octoperf, and is based in Marseille, France. * Octoperf is a full-stack cloud load testing SaaS platform. It allows developers to test the design performance limits of mobile apps and websites in a realistic virtual environment. As a startup, we are attempting to use containers to change the load testing paradigm, and deliver a platfrom that can run on any cloud, for a fraction of the cost of existing approaches.
In previous articles we have seen how to setup a Jenkins CI system on top of docker and leverage docker in order to create a continuous integration pipeline. As part of that we used docker to create a centrally managed build environment which can be rolled out to any number of machines. We then setup the environment in Jenkins CI and automated the continuous building, packaging and testing of the source.
](https://cdn.rancher.com/wp-content/uploads/2015/11/16025649/spotinstlogo.png) We are very excited to announce a new partnership with Spotinst today to deliver intelligent management and migration of container workloads running on spot instances. With this new solution, we have developed a simple, intuitive way for using spot instances to run any container workload reliably and for a fraction of the cost of traditional applications. Since the dawn of data centers we’ve seen continuous improvements in utilization and cost efficiency.
Hello, I’m Alena Prokharchyk, one of the developers here at Rancher. In my previous blog posts, I’ve covered various aspects of Service Discovery, a feature we use to discover and interconnect services of user applications deployed in Rancher. This discovery is done by services registering themselves dynamically to Rancher’s internal DNS so that other services in the system can discover them by fully qualified domain name (FQDN). Service Discovery can also be registered to Rancher’s Load Balancer (LB) service which allows it to balance traffic between all of a services’ containers.
Containerization brings several benefits to traditional CI platforms where builds share hosts: build dependencies can be isolated, applications can be tested against multiple environments (testing a Java app against multiple versions of JVM), on-demand build environments can be created with minimal stickiness to ensure test fidelity, Docker Compose can be used to quickly bring up environments which mirror development environments. Lastly, the inherent isolation offered by Docker Compose-based stacks allow for concurrent builds -- a sticking point for traditional build environments with shared components.
In my last post I showed you how to deploy a Highly Available Wordpress installation using Rancher Services, a Gluster cluster for distributed storage, and a database cluster based on Percona XtraDB Cluster. Now I’m going one step further and we are setting Gluster and PXC clusters using Rancher Services too. And now we are using new service features available on the beta Rancher release like DNS service discovery and Label Scheduling.
Note: Rancher has come a long way since this was first published in June 2015. We’ve revised this post (as of August 2016) to reflect the updates in our enterprise container management service. Read on for the updated tutorial!
Rancher supports multiple orchestration engines for its managed environments, including Kubernetes, Mesos, Docker Swarm, and Cattle (the default Rancher managed environment). The Cattle environment is rich with features like stacks, services, and load balancing, and in this post, we’ll highlight common uses for these features.
A little over a month ago I wrote about setting up a Magento cluster on Docker using Rancher. At the I identified some short comings of Rancher such as its lack of support fot load-balancing. Rancher released support for load balancing and docker machine with 0.16, and I would like to revisit our Magento deployment to cover the use of load balancers for scalability as well as availability. Furthermore, I would also like to cover how the docker machine integration makes it easier to launch Rancher compute nodes directly from the Rancher UI.
Since I started playing with Docker I have been thinking that its network implementation is something that will need to be improved before I could really use it in production. It is based on container links and service discovery but it only works for host-local containers. This creates issues for a few use cases, for example when you are setting up services that need advanced network features like broadcasting/multicasting for clustering.
Rancher Server has recently added Docker Machine support, enabling us to easily deploy new Docker hosts on multiple cloud providers via Rancher’s UI/API and automatically have those hosts registered with Rancher. For now Rancher supports DigitalOcean and Amazon EC2 clouds, and more providers will be supported in the future. Another significant feature of Rancher is its networking implementation, because it enhances and facilitates the way you connect Docker containers and those services running on them.
Recently I have been playing around with Riak and I wanted to get it running with Docker, using RancherOS and Rancher. If you’re not familiar with Riak, it is a distributed key/value store which is designed for high availability, fault tolerance, simplicity, and near-linear scalability. Riak is written in Erlang programming language and it runs on an Erlang virtual machine. Riak provides availability through replication and faster operations and more capacity through partitions, using the ring design to its cluster, hashed keys are partitioned by default to 64 partitions (or vnodes), each vnode will be assigned to one physical node as following: From Relational to Riak Whitepaper For example, if the cluster consists of 4 nodes: Node1, Node2, Node3, and Node4, we will count around the nodes assigning each vnode to a physical node until the all vnodes are accounted for, so in the previous figure, Riak used 32 partition with 4 node cluster so we get:
As you may have seen, Rancher recently announced our integration with docker-machine. This integration will allow users to spin up Rancher compute nodes across multiple cloud providers right from the Rancher UI. In our initial release, we supported Digital Ocean. Amazon EC2 is soon to follow and we’ll continue to add more cloud providers as interest dictates. We believe this feature will really help the Zero-to-Docker _(and Zero-to-Rancher)_ experience. But the feature itself is not the focus of this post.
[Usman is a server and infrastructure engineer, with experience in building large scale distributed services on top of various cloud platforms. You can read more of his work at techtraits.com, or follow him on twitter @usman_ismailor on GitHub.]
Magento is an open-source content management system (CMS) offering a powerful tool-set for managing eCommerce web-sites. Magento is used by thousands of companies including Nike and Office Max. Today we are going to walk through the process of setting up a Magento cluster using Docker and Rancher on the Amazon Elastic Compute Cloud (EC2).
Last week we introduced our new project, Rancher.io, at AWS Re:Invent, and it was amazing. We’d been working on the software for months, talking with good friends, old customers and former colleagues about what we were building and wondering how it would be received by users. We were anxious to share it with new people and eager to get their feedback. We were also really nervous. Four of us flew out to Vegas, set up our little booth, tested our demos and organized our piles of stickers and t-shirts.