Docker multi-stage builds were announced 2 years ago, but sadly not all developers are using them. Using multi-stage builds can result in a much more secure and smaller Docker image. In some cases, you can take a Docker image from 700MB to 20MB, which makes a big difference in the context of CI/CD. In this webinar, we will see how to use multi-stage Docker builds and the best practices around them.

Even though the public cloud has changed the way companies deploy and run applications, there are several cases (finance/healthcare) where all services of an organization are running in secure on-premise datacenters behind strict firewalls, in remote storefronts, or even in mobile locations with low connectivity.

Since its initial debut 5 years ago, Kubernetes has grown up quite a bit, but one thing hasn’t changed: writing Kubernetes manifest files from scratch is hard. In fact, it’s borderline discouraging for new users looking to use the de facto container orchestrator. Thus, the need for a package manager was born: Helm. Helm is almost as old as Kubernetes (it’s about 4 years old) and Helm 2 is a merger of two code bases, which made for some interesting ways of approaching even the most basic of security concerns (say, RBAC for instance). If you’re familiar with Helm you already know how useful it is, but there are features you’d like added, some updates you’ve wished for and a major component you’d like removed: Tiller.

Codefresh is the only CI/CD to offer interactive debugging with breakpoints. Start a pipeline in debug mode and add breakpoints just like you would with an IDE. You can run commands before steps or override a step to drop into the step container!

Docker Compose is great for local development, but an effective CI/CD pipeline will also need to execute integration tests after a commit is pushed. The easiest way to bring up extra services for integration testing (such as a database or a message queue) is by launching them alongside the main pipeline! In this webinar, you will see how easy is to launch multiple Docker containers in a single pipeline step, complete with health checks and service dependencies.

Since its initial debut 5 years ago Kubernetes has grown up quite a bit, but one thing hasn’t changed: writing Kubernetes manifest files from scratch is hard. In fact, it’s borderline discouraging for new users looking to use the defacto container orchestrator. Thus, the need for a package manager was born: Helm. Helm is almost as old as Kubernetes (it’s about 4 years) old and Helm 2 is a merger of two code bases, which made for some interesting ways of approaching even the most basic of security concerns (say, RBAC for instance). If you’re familiar with Helm you already know how useful it is, but there are features you’d like added, some updates you’ve wished for, and a major component you’d like removed: Tiller.

A few years ago, Codefresh revolutionized the CI/CD world and became the first container-native CI/CD platform.

You have finally split your big monolith into microservices. Now what? How do you validate a more complex application? And how do you make it scale? Instead of having one CI/CD pipeline, you have multiple. And as the number of microservices increases so does the number of pipelines. Managing pipelines for microservice applications can quickly get out of hand, especially when you try to reuse common pipeline parts between different applications.

Docker multi-stage builds were announced 2 years ago, but sadly not all developers are using them. Using multi-stage builds can result in a much more secure and smaller Docker image. In some cases, you can take a Docker image from 700MB to 20MB, which makes a big difference in the context of CI/CD. In this webinar, we will see how to use multi-stage Docker builds and the best practices around them.