Skip to content

CloudBees' Blog - Continuous Integration in the Cloud
Syndicate content
Updated: 23 hours 22 min ago

Join the Jenkins World Sticker Competition!

Tue, 08/16/2016 - 20:01

We’re thrilled to announce our first Jenkins Butler design contest! Design a unique version of the Jenkins Butler and submit it before September 9, 2016. Voting will take place at Jenkins World, at the sticker exchange booth hosted by Sticker Mule.

We partnered with Sticker Mule, so the winner who produces the winning design will get a $100 credit on stickermule.com to turn their designs into die cut custom stickers.

Please see how to enter and the rules for the competition below. If you have any questions, please contact us: fboruvka@cloudbees.com.

How to enter:

Entering the competition is easy. Just submit your design (ensuring the rules have been followed) and send it to fboruvka@cloudbees.com before September 9, 2016.

Rules:
  • One design per person
  • Must include the Jenkins Butler
  • Design would need to be sketched, drawn, digitally drawn including dimensions
  • The reason behind your design
  • All entries must be submitted before September 9, 2016
  • The design must be original (not been previously created, not copyrighted, etc.)

Good luck!

 

Blog Categories: Jenkins
Categories: Companies

Cluster Orchestration (The DevOps 2.0 Toolkit)

Mon, 08/15/2016 - 22:33

When I was an apprentice, I was taught to treat servers as pets. I would treat them with care. I would make sure that they are healthy and well fed. If one of them gets sick, finding the cure was of utmost priority. I even gave them names. One was Garfield, and the other was Gandalf. Most companies I worked for had a theme for naming their servers. Mythical creatures, comic book characters, animals and so on. Today, when working with clusters, the approach is different. Cloud changed it all. Pets became cattle. When one of them gets sick, we kill them. We know that there's almost an infinite number of healthy specimens so curing a sick one is a waste of time. When something goes wrong, destroy it and create a new one. Our applications are built with scaling and fault tolerance in mind, so a temporary loss of a single node is not a problem. This approach goes hand in hand with a change in architecture.

If we want to be able to deploy and scale easily and efficiently, we want our services to be small. Smaller things are easier to reason with. Today, we are moving towards smaller, easier to manage, and shorter lived services. The excuse for not defining our architecture around microservices is gone. They were producing too many problems related to operations. After all, the more things to deploy, the more problems infrastructure department has trying to configure and monitor everything. With containers, each service is self-sufficient and does not create infrastructure chaos thus making microservices an attractive choice for many scenarios.

With microservices packed inside containers and deployed to a cluster, there is a need for a different set of tools. There is the need for cluster orchestration. Hence, we got Mesos, Kubernetes and Docker Swarm (just to name a few). With those tools, the need to manually SSH into servers disappeared. We got an automated way to deploy and scale services that will get rescheduled in case of a failure. If a container stops working, it will be deployed again. If a whole node fails, everything running on it will be moved to a healthy one. And all that is done without human intervention. We design a behavior and let machines take over. We are closer than ever to a widespread use of self-healing systems that do not need us.

While solving some of the problems, cluster orchestration tools created new ones. Namely, if we don't know, in advance, where will our services run, how to we configure them?

The DevOps 2.0 Toolkit

If you liked this article, you might be interested in The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices book.

The book is about different techniques that help us architect software in a better and more efficient way with microservices packed as immutable containers, tested and deployed continuously to servers that are automatically provisioned with configuration management tools. It's about fast, reliable and continuous deployments with zero-downtime and ability to roll-back. It's about scaling to any number of servers, the design of self-healing systems capable of recuperation from both hardware and software failures and about centralized logging and monitoring of the cluster.

In other words, this book envelops the full microservices development and deployment lifecycle using some of the latest and greatest practices and tools. We'll use Docker, Ansible, Ubuntu, Docker Swarm and Docker Compose, Consul, etcd, Registrator, confd, Jenkins, nginx, and so on. We'll go through many practices and, even more, tools.

The book is available from Amazon (Amazon.com and other worldwide sites) and LeanPub.

Blog Categories: Developer Zone
Categories: Companies

Containers and Immutable Deployments (The DevOps 2.0 Toolkit)

Tue, 08/09/2016 - 21:05

Even though CM alleviated some of the infrastructure problems, it did not make them go away. The problem is still there, only in a smaller measure. Even though it is now defined as code and automated, infrastructure hell continues to haunt us. Too many often conflicting dependencies quickly become a nightmare to manage. As a result, we tend to define standards. You can use only JDK7. The web server must be JBoss. These are the mandatory libraries. And so on, and so forth. The problem with such standards is that they are an innovation killer. They prevent us from trying new things (at least during working hours).

We should also add testing into the mix. How do you test a web application on many browsers? How do you make sure that your commercial framework works on different operating systems and with different infrastructure? The list of testing combinations is infinite. More importantly, how do we make sure that testing environments are exactly the same as production? Do we create a new environment every time a set of tests is run? If we do, how much time does such an action take?

CM tools were not addressing the cause of the problem but trying to tame it. The difficulty lies in the concept of mutable deployments. Every release brings something new and updates the previous version. That, in itself, introduces a high level of unreliability.

The solution to those, and a few other problems, lies in immutable deployments. As a concept, immutability is not something that came into being yesterday. We could create a new VM with each release and move it through the deployment pipeline all the way until production. The problem with VMs, in this context, is that they are heavy on resources and slow to build and instantiate. We want both fast and reliable. Either of those without the other does not cut it in today's market. Those are some of the reasons why Google has been using containers for a long time. Why doesn't everyone use containers? The answer is simple. Making containers work is challenging and that's where Docker enters the game. First, they made containers easy to use. Then they extended them with some of the things that we, today, consider a norm.

With Docker we got an easy way to create and run containers that provide immutable and fast deployments and isolation of processes. We got a lightweight and self-sufficient way to deploy applications and services without having to worry about infrastructure.

However, Docker itself proved not to be enough. Today, we do not run things on servers but inside clusters and we need more than containers to manage such deployments.

The DevOps 2.0 Toolkit

If you liked this article, you might be interested in The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices book.

The book is about different techniques that help us architect software in a better and more efficient way with microservices packed as immutable containers, tested and deployed continuously to servers that are automatically provisioned with configuration management tools. It's about fast, reliable and continuous deployments with zero-downtime and ability to roll-back. It's about scaling to any number of servers, the design of self-healing systems capable of recuperation from both hardware and software failures and about centralized logging and monitoring of the cluster.

In other words, this book envelops the full microservices development and deployment lifecycle using some of the latest and greatest practices and tools. We'll use Docker, Ansible, Ubuntu, Docker Swarm and Docker Compose, Consul, etcd, Registrator, confd, Jenkins, nginx, and so on. We'll go through many practices and, even more, tools.

The book is available from Amazon (Amazon.com and other worldwide sites) and LeanPub.

This post is part of a new blog series all about the DevOps 2.0 Toolkit. Follow along in the coming weeks. Each post builds upon the last!

The DevOps 2.0 Toolkit
Configuration Management (The DevOps 2.0 Toolkit)
Containers and Immutable Deployments (The DevOps 2.0 Toolkit)
Cluster Orchestration (The DevOps 2.0 Toolkit) 
Service Discovery (The DevOps 2.0 Toolkit) 
Dynamic Proxies (The DevOps 2.0 Toolkit)
Zero-Downtime Deployment (The DevOps 2.0 Toolkit) 
Continuous Integration, Delivery, And Deployment (The DevOps 2.0 Toolkit)

Blog Categories: Developer Zone
Categories: Companies