This article walks though connecting GitLab's Auto DevOps feature to a Rancher-managed Kubernetes cluster using a Rancher feature called Authorized Cluster Endpoint.
This blog describes steps to migrate Rancher 2.1.x from a single node installation to a high availability installation.
Ankur Agarwal, Rancher's Head of Product Management, describes new features in Rancher 2.2. Learn how to monitor multiple Kubernetes clusters in this step-by-step tutorial and how our new preview release process works.
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.
Elasticsearch is a Lucene-based search engine developed by the open-source vendor, elastic. With principal features like scalability, resiliency, and top-notch performance, it has overtaken Apache Solr, one of its closest competitors. Nowadays, Elasticsearch is almost everywhere where a search engine is involved: it’s the E of the well-known ELK stack, which makes it straightforward for your project to process analytics (the L stands for Logstash which is used to process data like logs, streams, metrics; K stands for Kibana, a data visualization platform – projects also managed by elastic).
So far in this series of articles we have looked at creating continuous integration pipelines using Jenkins and continuously deployingto integration environments. We also looked at using Rancher compose to run deployments as well as Route53 integration to do basic DNS management. Today we will cover production deployments strategies and also circle back to DNS management to cover how we can run multi-region and/or multi-data-center deployments with automatic fail-over. We also look at some rudimentary auto-scaling so that we can automatically respond to request surges and scale back when request rate drops again.
[Recently Rancher introduced the Rancher catalog, an awesome feature that enables Rancher users to one-click deploy common applications and complex services from catalog templates on your infrastructure, and Rancher will take care of creating and orchestrating the Docker containers for you.] Rancher catalog offers a wide variety of applications in its out of the box catalog, including glusterfs or elasticsearch, as well as supporting private catalogs. Today I am going to introduce a new catalog template I developed for deploying a MongoDB replicaset, and show you how I built it.
Over the last year we have written about getting several application stacks running on top of docker, e.g. Magento, Jenkins, Prometheus and so forth. However, containerized deployment can be useful for more than just defining application stacks. In this series of articles we would like to cover an end-to-end development pipeline and discuss how to leverage Docker and Rancher in its’ various stages. Specifically, we’re going to cover; building code, running tests, packaging artifacts, continuous integration and deployment, as well as managing an application stack in production.
Today, our team at Rancher announced an exciting new feature called Persistent Storage Services. Persistent storage support builds on the work we’ve done with Rancher Convoy, and makes it dramatically easier to run stateful applications in production using Rancher. The Docker volume plugins, introduced in Docker 1.8 and further enhanced in Docker 1.9, enables developers to utilize a variety of persistent storage implementations as standard Docker volumes. Our new Persistent Storage Services capability complements Docker volume plugins by providing a backend implementation of a Docker volume plugin, and is the core storage technology in our recently announced hyper-converged infrastructure stack for Docker.
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.