Illumina Innovates with Rancher and Kubernetes
Partnership Combines Rancher 2.0 with Canonical Kubernetes and Leading Cloud OS, Ubuntu Today, we joined Canonical in announcing the Canonical Cloud Native Platform, a new offering that provides complete support and management for Kubernetes in the Enterprise. The Cloud Native Platform combines Rancher 2.0 container management software with Canonical Ubuntu and Ubuntu Kubernetes, and will be available when Rancher 2.0 launches next spring. This announcement is an enormous accomplishment for our team here at Rancher.
I just came back from DockerCon EU. I have not met a more friendly and helpful group of people than the users, vendors, and Docker employees at DockerCon. It was a well-organized event and a fun experience.
I went into the event with some questions[ about where Docker was headed. Solomon Hykes addressed these questions in his keynote, which was the highlight of the entire show. Docker embracing Kubernetes is clearly the single biggest piece of news coming out of DockerCon.
It’s finally here: the Rancher you’ve all been waiting for. Rancher 2.0 is now in preview mode and available to deploy! Rancher 2.0 brings us a whole new Kubernetes-based structure, with new features like platform-wide multi-select, adoption of existing Kubernetes clusters, and much, much more. If you’re looking to dive in with Rancher 2.0, you’ve come to the right place.
Assumptions You have a Linux host with at least 4 GB of RAM.
Since its founding in 2015, the Cloud Native Computing Foundation (CNCF) has become one of the most important movers and shakers in the open source ecosystem—especially when it comes to tools that affect containers and other “cloud-native” technologies. CNCF was established to promote and organize projects related to large-scale industry trends towards containerization, orchestration, and microservices architectures. In the time since, 10 open source projects have been added to the foundation.
Container security was initially a big obstacle to many organizations in adopting Docker. However, that has changed over the past year, as many open source projects, startups, cloud vendors, and even Docker itself have stepped up to the challenge by creating new solutions for hardening Docker environments. Today, there is a wide range of security tools that cater to every aspect of the container lifecycle. Docker security tools fall into these categories:
At Higher Education, we’ve tested and used quite a few CI/CD tools for our Docker CI pipeline. Using Rancher and Drone CI has proven to be the simplest, fastest, and most enjoyable experience we’ve found to date. From the moment code is pushed/merged to a deployment branch, code is tested, built, and deployed to production in about half the time of cloud-hosted solutions - as little as three to five minutes (Some apps take longer due to a larger build/test process).
One of the things that often surprises administrators when they first begin working with Docker containers is the fact that containers natively use non-persistent storage. When a container is removed, so too is the container’s storage. Of course, containerized applications would be of very limited use if there were no way of enabling persistent docker container storage. Fortunately, there are ways to implement persistent storage in a containerized environment. Although a container’s own native storage is non-persistent, a container can be connected to storage that is external to the container.
Containers may be super cool, but at the end of the day, they’re just another kind of infrastructure. A seasoned developer is probably already familiar with several other kinds of infrastructure and approaches to deploying applications. Another is not really that big of a deal. However, when the infrastructure creates new possibilities with the way an application is architected—as containers do—that’s a huge deal. That is why the services in a microservice application are far more important than the containerized infrastructure they run on.
Are you monitoring your containers’ resources in real time? If not, then you’re probably not monitoring as effectively as possible. In a fast-moving, dynamic microservices environment, monitoring data that is even seconds old may no longer be actionable. To prevent disruptions, you need real-time monitoring. In this post, I explain why real-time monitoring of container resources is important, and which types of container metrics you should focus on monitoring in real time.
Since Docker launched in 2013, it has brought a level of excitement and innovation to software development that’s contagious. It has rallied support from every corner—enterprises to startups, developers to IT folk, plus the open source community, ISVs, the biggest public cloud vendors, and every tool across the software stack. Since the launch of Docker, many major milestones have served to advance the container revolution. Let’s look at some of them.
We’ve just returned from DockerCon 2017, which was a fantastic experience. I thought I’d share some of my thoughts and impressions of the event, including my perspective on some of the key announcements, while they are still fresh in my mind.
New open source projects Container adoption for production environments is very real. The keynotes on both days included some exciting announcements that should further accelerate adoption in the enterprise as well as foster innovation in the open source community.
Modern microservices applications span multiple containers, and sometimes a single app may use thousands of containers. When operating at this scale, you need a container orchestration tool to manage all of those containers. Managing them by hand is simply not feasible. This is where Kubernetes comes in. Kubernetes manages Docker containers that are used to package applications at scale. Since its launch in 2014, Kubernetes has enjoyed widespread adoption within the container ecosystem.
What do Docker containers have to do with Infrastructure as Code (IaC)? In a word, everything. Let me explain. When you compare monolithic applications to microservices, there are a number of trade-offs. On the one hand, moving from a monolithic model to a microservices model allows the processing to be separated into distinct units of work. This lets developers focus on a single function at a time, and facilitates testing and scalability.
Last week we announced a partnership with EVRY, one of the leading IT companies in the Nordics, to deliver Rancher’s container management platform as a service to EVRY customers. This is an exciting moment for Rancher as the service will introduce our software to a new audience looking to embrace DevOps and transform how they deliver IT. Not surprisingly, our relationship with EVRY began last year when a couple of their cloud architects downloaded Rancher and built a small test deployment.
Registries are one of the key components that make working with containers, primarily Docker, so appealing to the masses. A registry hosts images that are downloaded and run on hosts in a container engine. A container is simply a running instance of a specific image. Think of an image as a ready-to-go package, like an MSI on Microsoft Windows or an RPM on Red Hat Enterprise Linux. I won’t go into the details of how registries work here, but if you want to learn more,this article is a great read.
Prometheus is a modern and popular monitoring alerting system, built at SoundCloud and eventually open sourced in 2012 – it handles multi-dimensional time series data really well, and friends at InfinityWorks have already developed a Rancher template to deploy Prometheus at click of a button.
In hybrid cloud environments, it is likely that one might be using multiple orchestration engines such as Kubernetes and Mesos, in which case it is helpful to have the stack or application portable across environments.
[We just came back from DockerCon 2016, the biggest and most exciting DockerCon yet. Rancher had a large and well-trafficked presence there - our developers even skipped attending breakout sessions in favor of staffing the booth, just to talk with all the people who were interested in Rancher. In only two days, over a thousand people stopped by to talk to us!]
[Docker-Native Orchestration] [Without a doubt, the biggest news out of DockerCon this year is the new built-in container orchestration capabilities in the upcoming Docker 1.
In case you missed it, we were at EMC World a couple of weeks ago, demonstrating how to build your own container service using RackHD, ScaleIO, and REX-Ray (all from EMC) and Rancher. Since then, we’ve gotten a lot of requests to walk through things in a bit more detail. While you can read through things on the emccode blog(split into part 1 and part 2), we’ve also assembled a short video on how we built the container service: https://vimeo.
Container logging is a common challenge for container deployments. Logging with containers is a bit different than traditional logging, because the logs for each container are nested within the container. On September 16th, we hosted an online meetup discussing all aspects of container logging, and demonstrating how to build a scalable logging service for Docker and Rancher that uses Elasticsearch, Logstash, and Kibana (ELK), along with Logspout. In the meetup Rancher DevOps lead Bill Maxwell discussed: • Docker Logging Challenges • Options for gathering logs from containers • System and Application logging requirements • Deploying an ELK stack using Docker Compose with Rancher • Scaling and managing a production ELK deployment You can view a recording of the meetup below.
I have already talked about several ways to monitor docker containers and also using Prometheus to monitor Rancher deployments. However, until now it has been a manual process of launching monitoring agents on our various hosts. With the release of the Rancher beta with scheduling and support for Docker compose we can begin to make monitoring a lot more automated. In today’s post we will look at using Rancher’s new \“Rancher compose\” tool to bring up our deployment with a single command, using scheduling to make sure we have a monitoring agent running on every host, and using labels to isolate and present our metrics.
GlusterFS is a scalable, highly available, and distributed network file system widely used for applications that need shared storage including cloud computing, media streaming, content delivery networks, and web cluster solutions. High availability is ensured by the fact that storage data is redundant, so in case one node fails another will cover it without service interruption. In this post I’ll show you how to create a GlusterFS cluster for Docker that you can use to store your containers data.
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.
In this article, Rancher compares seven Docker monitoring options and goes over some of the common tools used to monitor containers. Visit us to learn more.
[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).
In addition to managing container networking across cloud providers, we are excited to announce the following features in Rancher v0.2. First up, the team has exposed the building blocks for storage management.