ALU

continuos delivery

CI/CD With Kubernetes and Helm

In this blog, I will be discussing the implementation of CI/CD pipeline for microservices which are running as containers and being managed by Kubernetes and Helm charts

Note: Basic understanding of Docker, Kubernetes, Helm, and Jenkins is required. I will discuss the approach but will not go deep into its implementation. Please refer to the original documentation for a deeper understanding of these technologies.

Original Link

Top 11 Continuous Delivery Tools for Kubernetes (Part 2)

In Part 1 of this series, we looked at tools grouped under Package Managers and CI tools with CD support for Kubernetes. In part 2 we will discuss the tools that fall under the CD-only category.

CD-Only Tools

This group contains tools that do only one thing—primarily Continuous Delivery to Kubernetes. With these tools you can choose the CI system that you want, the container registry, but the CD portion will be taken care of for you.

8. Weave Cloud

Weave Cloud is a SaaS that can automatically deploy your application updates to a running Kubernetes cluster. Weave Cloud works alongside your existing CI system and Image repository and handles your deployments to Kubernetes.

When a developer makes a code change and pushes it to ‘git’ or any other Version Control System, it triggers the deployment pipeline. As advocates of the GitOps methodology, a Git push is the catalyst for the pipeline and is also the source of truth for declarative configuration for Kubernetes, deployments manifests as well as source code.

Pros: Weave Cloud is one of the only Continuous Deployment solutions that keeps your cluster credentials secure inside the cluster where they belong. With Weave Cloud an agent acts on behalf of the cluster to listen to events relating to custom resource changes, so they can be consistently applied. The operator that sits inside of your cluster is responsible for synchronizing what’s in Git with what’s running in Kubernetes. It has a pull pattern rather than push where credentials can be leaked outside of the cluster during a deploy.

For more information on this topic see, Approaches to Continuous Delivery in our Kubernetes Library.

Cons: Helm support is currently only in Alpha and requires a little bit of configuration to get working properly.

9. Spinnaker

Developed by Netflix, Spinnaker is an open source tool that manages deployments and pipelines and supports Helm charts. Spinnaker supports any CI tool and cloud provider and it can also handle blue/green and canary deployments.

However, the tool was originally developed to manage VMs and not Kubernetes objects, and can be complex to set up and maintain since it uses a slightly different paradigm.

10. Codefresh

Codefresh s a continuous delivery pipeline tool that also supports Helm charts. Codefresh is a GUI-based environment for building and deploying your applications. It allows you to hook up to and use your favorite repo, CI and image repository. Codefresh has an extensive set of plugins that includes Helm as well as many of the other popular CI/CD tools like Jenkins.

An advantage of Codefresh is that you are free to continue using your favourite tools. But a disadvantage is that third-party tools are setup from their GUI and so when things go wrong it adds another layer of complexity to your pipeline. Codefresh also doesn’t solve the problem of cluster credentials living outside of the cluster which can leave your cluster vulnerable to attacks.

11. Harness

Harness is a delivery as a service. It provides the ability to build out a complete pipeline and also has security at the centre of its pattern. It runs as a SaaS which means you don’t have to worry about setting it up yourself. It also supports a GitOps style of development, hooks into your Git repository and has secrets management.

However, unlike Weave Cloud, it is not agnostic and it only supports a subset of tools out there. This means that you must choose one of the CI tools or one of the repositories that it supports.

In Conclusion

These are the main differences between these 11 different tools. The things we focused on were whether security has to be built separately from the tool, the complexity of set up, whether it’s open source or not, and the approach taken, is it a Pull type pipeline rather than a Push type architecture.

Tool

Built-in Security

Complexity

OSS/ closed source?

Pull vs Push?

Works with most tools

Package Managers

Helm

No

high

OSS

Push

Yes

Draft

No

high

OSS

Push

No

ksonnet & jsonnet

No

Medium

OSS

Push

No

CI Tools with K8S support

Jenkins

No

High

Both

Push

Yes

CircleCI

No

High

Closed

Push

Yes

Gitlab

No

Low

Closed

Push

No

Travis

No

High

OSS

Push

Yes

CD Only tools

Weave Cloud

Yes

Low

Both

Pull

Yes

Spinnaker

No

High

OSS

Push

No

Codefresh

Yes

Medium

Closed

Push

Yes

Harness

Yes

Low

Closed

Push

Yes

Original Link

The 2018 Olympic Games and Agile

The 2018 Winter Olympic games are well underway, completing events in a time zone that is fourteen hours ahead of my local time zone. However, having a six-month old baby in the house, leads to some middle-of-the-night one-on-one time with our son. This situation has worked out well as the Olympic games are being played — providing an alternative to infomercials or stale news broadcasts that are typically the only real view choice while rocking our son back to sleep.

Watching the Olympic games made me wonder what parallels exist within the Agile development lifecycle.

The Opening Ceremonies

The opening ceremonies are the point where participants are focused on celebrating the beginning of the games they have worked the majority of their lives to reach. In hearing some of the Olympians describe the feeling, several mentioned the high degree of loudness and awe of the event to cause them to hear nothing more than silence. As each country enters the arena, the cheers cast across the stadium catapulted the group into utter stardom. To those athletes, the thrill of being recognized and appreciated is equally as exciting of being able to compete on a worldwide stage.

While not nearly as glamorous, a project kickoff meeting is similar to the opening ceremonies. For each person in attendance, they were chosen to participate based upon their strengths and abilities to help the project reach the expected goals. As a member of the team, there is an excitement of a new project before them, being able to provide their thoughts and opinions on providing the best solution possible. The thrill here is to be recognized as part of the team that will meet a need important enough to garner budgeted funds from the application’s sponsor.

Speed Skating Relay

Watching the speed skating events are very cool. That track is quite small and the racers are often what appears to be a hair’s length from each other. A single mistake can lead to multiple racers being tossed aside. I was amazing when the relay version of the race started, as each team had multiple members racing on the track for a given event. One member was on the track, another was inside the track getting up to speed to take over (boosted with a push from the prior racer) and two others team members waited for their opportunity to participate in the 45-lap event. There is a lot going on to complete the event.

To me, the speed skating event on an Agile team would be the CI/CD component, where several participants come together for a common goal: to obtain a successful build. The pipeline implemented by DevOps pulls in the source code from the development team member, validates and analyzes the code being built, executes the build, and deploys the build to a container for others to utilize. One mistake can lead to a cascading effect, causing the build to fail.

Figure Skating

For the most part, I am pretty good at being able to understand the games and what it takes to become a winner. Even the sport of curling was not that difficult to understand and follow. Where I struggle is being able to know what is good and what is great when it comes to events that are scored based on style points. Like the figure skating events. I have no idea what gains huge points with the judges and what yields a lower score. In fact, I thought that a wipe-out would eliminate the possibility for a first-place gold medal, but the 2018 games proved that is not a valid assumption.

The parallel to Agile in this respect is completion of a given feature itself. Perhaps the feature is focused on building a shopping cart for an application. While I understand that the shopping cart process should allow a user to complete an order. At the same time, the shopping cart should not crash, lose some items while processing or even not correctly persist the expected costs from stage to stage. However, I am not sure I have a clear understanding on the style points involved. As a developer, I can make sure the need is being met, but I can only do as best as I can with a very limited understanding of what the customer (parallel to the judge in a figure skating event) is expecting.

I honestly believe this disconnect — because it is subjective — is a reason why features are often considered not working as expected when delivered to the customer.

Conclusion

In the past I have found parallels with television shows Dateline and Live PD, as well as The Weather Channel and the Call of Duty video game. I wasn’t surprised that I was able to find similarities with the 2018 Olympic games, especially while watching the games being played in the middle of the night as I steadily rock my son.

Have a really great day!

Original Link

A 5-Step Guide to Good Continuous Delivery

At Caylent, we believe one of the major keys to successful DevOps implementation is the complete automation of Continuous Delivery (CD) and Continuous Deployment. Achieving full CD with your IT team unlocks many of the benefits that the DevOps ecosystem has to offer and ensures that you release code swiftly and with fewer errors.

Supported by the findings in the 2017 State of DevOps report, with the combined power of CD and DevOps high-performing IT teams can deploy code 46X more frequently than low-performing ones. Furthermore, you gain:

  • Meantime to recover: 24X faster.
  • 2555X faster lead time, from starting code to delivery.
  • Considerably lower failure rate: Just 0-15% rather than 31-45%.

Why Continuous Delivery?

CD aims to significantly reduce your risk level by enabling deployment of small, high-quality batches of code quickly and sustainably. The concept works in line with Continuous Integration, which focuses on helping your team prepare for deployment with ease.

A very interesting theory to note is that CD has also been demonstrated to positively impact the level of happiness and engagement of your team.

Put simply, a better work process = high-quality code = high-quality products = happy customers = happy IT team.

Continuous Delivery vs. Continuous Deployment

The difference between the two is minimal, and often, the terms are used interchangeably; the variation only comes in at staging or pre-production with a manual acceptance test for Continuous Delivery. At this point, the product owner will manually merge and push the code to production.

How Docker Improves CD

Docker gives us the ability to build and distribute immutable artifacts so that we can retain the exact same build artifact through testing, pre-production, and production. In comparison to Chef, Puppet, or other general server builders, Docker allows users to build first then push to servers, whereas Chef and Puppet users must build and modify the servers in real time. Once built, Docker allows you to move an artifact through the pipeline intact.

This advantage improves the artifact’s robustness and reduces the risk of failures and blockages in the production pipeline. Building an immutable artifact once also allows us to test the image repeatedly via local, QA, staging, and production environments. Rollbacks occur in seconds rather than minutes, and deployments are fast and straightforward. Finally, Docker further decouples server config from application deployment.

The 5 Steps

Caylent’s best practices when it comes to using Docker to empower CD can be broken down into these 5 steps:

  1. Where possible, build your packages once and once only. Then move your immutable artifact through your CD pipeline to test it from one repository to the next. As it migrates through the pipeline, leverage Docker’s tagging system to promote your image and gain the most stability for deployment.

  2. Decouple your code, database migrations, and infrastructure changes to independent pushes. Keep them separate and your code chunks as small as possible.

  3. Run your deployment types in the exact same manner in each environment, and in at least one environment that’s an identical mirror of production. Use the environment parameters and secrets within Docker to pass environment variables at runtime without drastically changing your artifact. Consider changes to these as Infrastructure-level change.

  4. Run tests as part of the container build process and automate the testing of all your deployments. Aim to combine builds and tests together to keep the log files intact and easy to decipher. If a build fails it will remain in the loop, rather than being promoted to the next environment.

  5. Keep your stacks and environments similar. If you’re running massive web stacks on your production site, this may be difficult in development and staging, but things like your content delivery network (CDN), proxies, and caches should all be replicated in staging.

While Docker makes it easy to deploy code using CD, it’s important to follow these best practices to build, test, and deploy correctly, rather than falling into bad habits.

In the companion article to this one, I cover the four main deployment types for Continuous Delivery with Docker. Click here for Docker and Continuous Delivery Deployment Types

Original Link