Buildpacks: Deploy to Kubernetes without Dockerfile

In the world of cloud-native and containerization, there are not only many levels of abstraction but so many ways to build out your cloud-native environments. Kubernetes is a go-to solution for orchestrating containers and scaling applications. But, before using Kubernetes, you must have a container image, and there are several ways to build a container image.

In this blog, we’ll talk about one of the most commonly used cloud-native tools used for building container images i.e., Buildpacks. It was initially launched by Pivotal and Heroku in January 2018 and later on donated to Cloud Native Computing Foundation (CNCF) on October 2018. In this blog, we’ll learn about how easily one can migrate from a non-containerized environment to a container ecosystem.

What are Cloud Native Buildpacks?

Cloud Native Buildpacks are pieces of software that analyze your source code and figure out the best way to build it. Buildpacks are essentially collections of two binaries

1. Detect - This binary looks at the application source code. It looks at the language specs and figures out that the application is written in a specific programming language. For e.g., If it detects go.mod file then it will figure out that the underlying codebase is a Golang application.
2. Build - Build is something that builds your container image, and it is the one that makes your image runnable. During this stage, your code gets compiled, and you get a container image ready to be deployed.
   

It embraces modern container standards, such as the OCI image format. They take advantage of the latest capabilities of these standards, such as cross-repository blob mounting and image layer "rebasing" on Docker API v2 registries.

Why do you need Cloud Native Buildpacks?

Across the industry, Dockerfile is the most common and go-to approach for building container images. With a couple of commands, you can easily build Docker images and push them to the respective container registry. Even though writing Dockerfiles is not so complicated, all thanks to wonderful documentation and a vibrant community, writing and managing Dockerfiles are still a manual job and it can become a hectic task to manage thousands of microservices.

Cloud Native Buildpacks support almost all the popular languages and frameworks. It has become popular in the world of modern application development and deployment for several reasons:

• Portability: It provides a consistent and standardised way to package and build applications, regardless of the underlying infrastructure or platform. This portability ensures that applications built with Buildpacks can be easily deployed across different cloud providers or on-premises environments without major modifications.
• Ease of Use: Buildpacks abstract out the complexity of setting up and managing build environments. Developers don't need to worry about configuring specific build tools, dependencies, or runtime environments. Buildpacks automatically analyze the application's code and determine the necessary components, streamlining the build process.
• Scalability: You can create lightweight and optimized container images. This leads to faster startup times, smaller image sizes, and efficient resource utilization, all of which are crucial for scalable and responsive applications.
• Language Agnostic: Irr-respective of any programming language you are using, Buildpacks can easily analyze the source code and build an OCI-compliant container image for your application.
• Vibrant Community: Cloud Native Buildpacks is an open-source and CNCF incubating project. This ensures ongoing development, improvements, and support from a wide range of contributors.
• Continuous Integration/Continuous Deployment (CI/CD): Cloud Native Buildpacks fit well into modern CI/CD pipelines. They allow for automated and consistent building and packaging of applications as part of the deployment process, promoting efficient development workflows.

Cloud Native Buildpacks Integration with Devtron

Kubernetes itself is a complex piece of software to handle and work around. If using vanilla Kubernetes, it becomes really complex to handle complicated applications using different K8s objects such as PersistentVolumes, ConfigMaps, Services, RBAC, ServiceAccount, and much more. Getting into Kubernetes and the container ecosystem is still a dream of many organizations. For migrating into Kubernetes and scaling, Devtron provides a one-stop solution. It is on a mission to democratize Kubernetes adoption by abstracting out all its complexities and providing a user-intuitive interface for creating Kubernetes-native CI/CD pipelines to build and deploy your applications onto Kubernetes. It uses some of the most trusted and community-adopted cloud-native tools such as ArgoCD, Grafana, Trivy, Helm, Casbin, NATS, Dex, and much more to provide the easiest path for migrating into Kubernetes and container ecosystem

The integration of Cloud Native Buildpacks represents a significant stride towards democratizing the adoption of Kubernetes. When combined with Devtron’s intuitive dashboard and the streamlined container creation facilitated by Buildpacks, it becomes the icing on the cake for organizations considering a migration or scaling with Kubernetes.

Let’s dive into hands-on and see how easily you can deploy an application on Kubernetes without writing any Dockerfile.

Deploy to Kubernetes without Dockerfile

Step-1: Create an Application
On the home page, click on Create in the top right corner and then create a custom application.

Step-2: Adding your Git Repo
Now, you need to give  Git Repo URL i.e, repository for the source code. This will be pulled during the build time. I’m using GitHub public here, but you can use any Git-hosted registry including GitLab, Bitbucket, etc.

Save this and move to the next page which is Build Configuration.

Step-3: Setting your Build Configuration
Devtron supports three types of build methods, which are listed below:

1. Dockerfile - In this method, you have your Dockerfile within the git repo itself and you take that Dockerfile to build the image.
2. Dockerfile on the go - This is helpful when you don’t have Dockerfile in your git repo. In this case, you can write your Dockerfile right in the browser and use the same. It comes with templates so you only need to change the arguments and values.
3. Buildpacks - This is the latest addition and with this feature, you don’t require Dockerfile. You can build your container image hassle-free.

Now comes the most important step, where you will select your buildpacks-related configurations.

As mentioned earlier, cloud-native Buildpacks support a variety of languages and frameworks, you can use any application that’s written in your language of choice and build your image.

You can choose any of the builders from the options. It's expected not all the builders would be able to build all types of applications, so you can select builders suitable for your source code. For instance, golang application can be build by using gcr.io/buildpacks/builder:v1.

Save this and move to the next page which is the deployment template.

Step-4: Choosing the deployment template
Choose the base deployment template. If you are not sure about how you can use your base deployment template, then read more about it here.

It will be the default configuration for now, but you can customize it according to your needs.

Save this and move next.

Note If you need even more configuration, you can click on the advance YAML and then edit the fields as needed.

Step-5: Creating CI-CD workflows
Now comes the part of creating the workflows. Let’s create a complete CI/CD workflow and see how easy it is to create one.

Click on the build and deploy from the source code which will help you build your applications and deploy from Devtron.

In the build pipeline, select your branch type (for now devtron support branch fixed, Regex, and two webhook named Tag creation & Pull Request)  configure the branch name respectively and click on Create Pipeline.

If you want to set up the advanced configuration then can Click on Advanced Option and can override any of the parameters. For e.g., You can set up pre-build stages and post-build stages in your build pipeline.

Here’s what the complete build stage looks like. If you want your container image to be scanned, then you can toggle on the Scan for vulnerabilities.

Note: At this stage, one can override the configuration for different workflows by clicking Allow override.

Now click on Create or Update pipeline and your will pipeline will be created. The pipeline will look like the below image.

In the next step, let’s create a CD pipeline that will deploy the built image to the cluster.  We're choosing a rolling deployment strategy here, but you can select others as well.

Step-6: Triggering CI & CD workflows
To trigger that pipeline, move to the Build & Deploy section and select the commit.

You will see that CI is running in the Build History Tab, and you’ll be able to see the logs.

Once the CI is complete, you can check your artifacts, source code against which image was built as well as scanning reports is it was enabled on the same page.

After our image build is completed using Buildpacks, we can use the same image to deploy it in the cluster.

For that, go to the Build & Deploy section and there you’ll be able to select the image that you just built.

When you’ll click on Deploy, the deployment will start and after successful deployment you can see the status as shown below. You can also track the progress of application deployment and the status that you see on App Details tab are the real-time status fetched from ArgoCD if using GitOps based deployment.

Conclusion

Hurray!! We have successfully deployed an application without Dockerfile by leveraging Buildpacks integration with Devtron. This can be really helpful when you have multiple applications with different behaviours that need to be containerised and deployed on Kubernetes. With Devtron’s user-friendly dashboard, it becomes really easy to set up CI/CD pipelines for Kubernetes to deploy an application just with a few clicks.

Don't forget to apply security best-practices to your containers.

If you have any questions, feel free to join our discord community and ask. Also if you like what we are building, do start the Devtron repo. All feedback and suggestions are welcome.