In our previous announcement for the removal of the Codefresh Docker registry, we presented a timeline of the migration phases along with the actions expected from our customers.
One of the milestones in the migration process is the introduction of our new Image API along with several enhancements on the pipeline build step. We believe that these features deserve a dedicated explanation of why they are useful on their own (regardless of the registry removal).
These enhancements have been on the roadmap for some time now as they fulfill one of the main promises of Codefresh regarding full traceability.
The promise of full traceability within a Codefresh pipeline
We’ve always envisioned Codefresh as a single platform that gives you the full story on what happens during a release—from the source code commit until the actual production deployment.
To this end, unlike other solutions that are focused purely on Continuous Integration (CI), Codefresh also covers Continuous Delivery (CD). We have invested considerable effort to provide a set of graphical dashboards in Codefresh that can help you understand the whole software lifecycle from a single application.
Codefresh is a single view plane, meaning you could first visit your Helm releases dashboard, look at a release, then find the Docker image deployed, click on it to see the pipeline that created it and finally reach the original commit.
With other solutions, you’re forced to look at different applications in different places in order to understand what is going on. Usually, you need to look at your CI system to get information on the build, then visit your Artifact manager to see the status of a release, and finally visit your cluster provider to see if the release is in production yet.
It is therefore very easy to answer all the classic questions of the release process using just Codefresh:
- What version of our application is deployed on cluster X?
- Has version Y moved from our staging to production yet?
- What was the last commit that affected environment Z?
The promise of full traceability is even more critical for companies that have adopted Helm in addition to Docker/Kubernetes as currently Codefresh is the only solution that has a wealth of Helm dashboards.
For example, apart from the usual “environment” dashboard that you might have seen in other CD solutions, Codefresh also has a promotion dashboard where you can not only see the status of a Helm release among different clusters (or namespaces), but also promote a release with a single drag-n-drop action.
In a similar manner, you can also demote a release very easily. For example, if a bug is found in production you can move that release back into staging or another environment for regression testing.
Actions like this are transparent in Codefresh and all project stakeholders can view in a visual manner the journey of a release within the software development process.
Using external registries with Codefresh
Another major tenet of Codefresh is the support of multi-cloud installations without any particular preference towards a cloud provider. Codefresh can connect to any compliant Kubernetes cluster and also integrate with any Docker registry that follows the Docker registry specifications.
Our customers are free to connect as many registries (and clusters) into their pipelines from the same or different cloud providers and Codefresh will be able to push/pull images in the same way in the Codefresh registry.
While flexibility is certainly important for multi-cloud installations, it also affected the promise of full traceability. We don’t force customers to follow a specific workflow regarding external registries and all combinations are possible:
- You can use only the Codefresh registry that comes built-in.
- You can use one or more external registries in addition to the Codefresh registry.
- You can ignore the Codefresh registry and use only external registries.
But this means that customers who use external registries now have an additional dashboard to manage apart from looking at Codefresh. If for example, a company is using an external registry for production deployments, the Docker image dashboard offered by Codefresh was not enough, as (until recently) it only showed images from the Codefresh registry.
Customers were then forced to look at multiple places to understand where their images are stored. This is exactly what we want to avoid, as trying to correlate similar actions among different platforms is always a big challenge.
The solution to this problem is to extend our image dashboard to show images from external registries even when they belong to different providers and not just the Codefresh registry.
This is a ground-breaking new feature as it not only fulfills the promise of full traceability but also helps companies with multi-cloud installations gain a single point of view regardless of the actual location of the registry.
Customers that use multiple registries will no longer have to hunt down image tags and hashes among different cloud dashboards to understand where an image is stored. Everything is now centralized in a single Codefresh dashboard as the image dashboard shows images from ALL connected registries.
The same is also true for our image API, which allows you to handle Docker images from different external registries in a unified way.
Changing the auto-push behavior of pipelines
One of the main features of the Codefresh registry is that all successful pipelines automatically push their Docker images to it. This makes pipeline creation in Codefresh very easy as no manual Docker login/push commands are needed. In other CI solutions, developers need to spend a lot of time with registry authentication before even running the pipeline, while in Codefresh the whole process is automatic.
While this automatic behavior is very welcome for most companies, as more people become accustomed to containers, they need extra flexibility in their pipelines in regards to which registry is used for auto-pushing.
The current auto-push behavior is great for companies who prefer to use the Codefresh registry as a “DEV” registry where most Docker images end up, but still want to use an external registry for production images. However, we want to offer as much flexibility as possible even to companies that prefer a completely different approach.
For speed and cost reasons it makes more sense to place your Docker images close to the systems that are going to use it. And the Codefresh Docker registry might not always be the closest registry to your systems.
This is why we now introduce a new way to handle the auto-push process of pipelines. You can now:
- Completely disable the auto-push behavior.
- Define another external registry that will be used for auto-push on a global account level.
- Define another external registry for auto-push for a specific pipeline.
This means that you are no longer limited to using the Codefresh registry as a DEV registry, but instead, you can mix and match registries as you wish.
Some of the possible scenarios are:
- Use an on-prem registry for Dev image and a cloud one for prod images.
- Use dev, staging, prod registries on 3 different cloud providers.
- Use just Dockerhub as a dev registry (in the case of a fully open source product).
These are just some ideas. The important point is that as a customer you are in control of the auto-push behavior.
Also notice that there is still the dedicated push step for tagging multiple images into multiple registries in a single pipeline.
The end result is that any kind of workflow between one or more Docker registries is now possible.
In this article, we explained some of the flexibility and benefits that you will gain from the new enhancements in the build steps and the Docker registry integration of Codefresh.
Even though these enhancements are rolled out at the same time as the Codefresh registry deprecation, it should be clear that these new features stand out on their own and can improve your pipeline workflows and artifact storage processes.
New to Codefresh? Create Your Free Account Today!