Containers generally deploy faster and perform better than virtual machines. Visit Rancher to explore five tips for making Docker technology faster.
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.
In the first part of this post, I created a full Node.js application stack using MongoDB as the application’s database and Nginx as a load balancer that distributed incoming requests to two Node.js application servers. I created the environment on Rancher and using Docker containers. In this post I will go through setting up Rancher authentication with GitHub, and creating a webhook with GitHub for automatic deployments. Rancher Access Control Starting from version 0.
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.
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
Running Drone as a Rancher Service for Dockerizing Builds On August 13th, Darren Shepherd and Shannon Williams hosted an online meetup demonstrating how our team at Rancher uses Drone.io, Docker and Rancher to build a scalable CI platform for builds and test environments. Rancher engineer Bill Maxwell gave a demonstration of how he built Rancher’s CI platform, and provided a Docker Compose file for anyone interested in deploying it themselves.
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).
Introduction Jenkins has been the industry standard CI tool for years. It contains a multitude of functionalities, with almost 1,000 plugins in its ecosystem, this can be daunting to some who appreciate simplicity. Jenkins also came up in a world before containers, though it does fit nicely into the environment. This means that there is not a particular focus on the things that make containers great, though with the inclusion of Blue Ocean and pipelines, that is rapidly changing.
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. Ever been there? How about the late night when your provisioning scripts work for updating existing servers, but not for creating a brand new environment?
Raul Sanchez is a microservices and Dev0ps architect in the innovation department at BBVA, exploring new technologies, bringing them to the company and the production lifecycle. In his spare time, he is a developer who collaborates on open source projects. He’s spent more than 20 years working on GNU/Linux and unix systems in different areas and sectors. Introduction GoCD is a Java open source continuous delivery system from ThoughtWorks.
In this article we'll walk through using Rancher to deploy and manage JFrog Artifactory on a Kubernetes cluster. When you have finished reading this article, you will have a fully functional installation of, and you can use the same steps to install the OSS or commercial version of Artifactory in any other Kubernetes cluster.
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.
The cloud vs. on-premises debate is an old one. It goes back to the days when the cloud was new and people were trying to decide whether to keep workloads in on-premises datacenters or migrate to cloud hosts. But the Docker revolution has introduced a new dimension to the debate. As more and more organizations adopt containers, they are now asking themselves whether the best place to host containers is on-premises or in the cloud.
At 360pi, we deliver commerce analytics that enable retailers to make sense of retail and shopper big data, which will then be used to improve their commerce strategy. Our infrastructure is all in Amazon Web Services, and up until now, was simply Ec2 instances built with our own AMIs. We used to maintain the traditional dev/test/master branch hierarchy in GitHub for our monolithic Python application, and we deployed those branches with Jenkins and Ansible scripts.
Is service-oriented architecture, or SOA, dead? You may be tempted to think so. But that’s not really true. Yes, SOA itself may have receded into the shadows as newer ideas have come forth, yet the remnants of SOA are still providing the fuel that is propelling the microservices market forward. That’s because incorporating SOA principles into the design and build-out of microservices is the best way to ensure that your product or service offering is well positioned for the long term.
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.
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.
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.
*Note: This post is the first in a two-part series on using GitLab and Rancher together for continuous integration and deployment, and part two is now up. We’ve also made the entire walkthrough available for download. * Introduction GitLab is, at its core, a tool for centrally managing Git repositories. As one might expect form a platform that provides this service, GitLab provides a robust authentication and authorization mechanism, groups, issue tracking, wiki, and snippets, along with public, internal, and private repositories.
*This is part two of our series on using GitLab and Rancher together to build a CI/CD pipeline, and follows part one from last week, which covered deploying, configuring, and securing GitLab in Rancher. We’ve also made the entire walkthrough available for download. * Using GitLab CI Multi-Runner to Build Containers GitLab CI is a powerful tool for continuous integration and continuous delivery. To use it with Rancher, we’ll deploy a runner that will execute jobs.
During the meetup Darren Shepherd demonstrated how to deploy a complete container stack On July 15th, Darren Shepherd and Shannon Williams hosted an online meetup demonstrating how to deploy a pilot Docker Service, and teaching attendees how to implement an integrated stack that included DockerHub, GitHub, Rancher, Jenkins and Prometheus. We’ve recorded the meeting and shared it below. You can register for our next online meetup on our events page.
Docker has been a source of excitement and experimentation among developers since March 2013, when it was released into the world as an open source project. As the platform has become more stable and achieved increased acceptance from development teams, a conversation about when and how to move from experimentation to the introduction of containers into a continuous integration environment is inevitable. What form that conversation takes will depend on the players involved and the risk to the organization.
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, you can find them here: 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 This post is the first in a series in which we’d like to share the story of how we implemented a container deployment workflow using Docker, Docker-Compose and Rancher.
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.
One of the exciting things about RancherOS is the concept of running system services as containers. It offers the chance to clearly delineate between containers running an application, and containers running agents and operating system services. This has some interesting potential implications for managing operations, such as making patching and upgrading system services simpler, setting app and organizational policies for required services, and prioritizing which services have access to system resources.