# Knative + Buildpacks: Source code to container image without Dockerfile

Author: [Mete Atamel](https://atamel.dev/) | Published: 2019-05-16 | Updated: 2020-04-12 | Topics: Knative, Serverless, Containers, DevOps, Cloud Computing | Canonical: https://atamel.dev/posts/2019/05-16_knative---buildpacks--source-code-to-container-image-without-dockerfile/


![](/img/2019/1__Sj53JniX4gStXhMQ5MkEcQ.png)
![](/img/2019/1__hUr6dlRbTCHwoGbVZg3Ivg.png)

I previously [talked about](https://medium.com/google-cloud/hands-on-knative-part-3-d8731ad2f23d) [Knative Build](https://github.com/knative/build) and how it enables you to go from source code to a container image in a repository. You can write your Build from scratch or you can rely on many of the [BuildTemplates](https://github.com/knative/build-templates) Knative already provides. For example, in my [Knative Tutorial](https://github.com/meteatamel/knative-tutorial), I [show](https://github.com/meteatamel/knative-tutorial/blob/master/docs/10.5-kanikobuildtemplate.md) how to install [Kaniko BuildTemplate](https://github.com/knative/build-templates/tree/master/kaniko) and use Kaniko to build container images.

You normally need to write a `Dockerfile`, so Knative Build (or Kaniko to be more precise) knows how to build the container image. Wouldn’t it be great if there was a an automatic way to build your app without having to define a `Dockerfile` ? Well, there is!

[Cloud Native Buildpacks](https://buildpacks.io/) is a project that provides a higher-level abstraction for building apps compared to Dockerfiles. [Cloud Native Buildpacks](https://buildpacks.io/) allow you to go from source code to a container image without having to define a `Dockerfile`. It does this with some auto-detection magic to figure out what language your code is written in and what kind of dependencies it has. In the end, you end up with a runnable app image without having to worry about the details of authoring and optimizing a `Dockerfile`.

The good news is that Knative has a [Buildpacks template](https://github.com/knative/build-templates/tree/master/buildpacks) that makes it really easy to use Buildpacks in your Knative Build. I show how to do this in my Knative Buildpacks Build Template [tutorial](https://github.com/meteatamel/knative-tutorial/blob/master/docs/10.7-buildpacksbuildtemplate.md) in detail but let’s recap here.

### Install the Buildpacks template

First, you need to install the Buildpacks template:

```sh
kubectl apply -f https://raw.githubusercontent.com/knative/build-templates/master/buildpacks/cnb.yaml
```

And check that the template is installed:

```sh
kubectl get buildtemplate

NAME             AGE  
buildpacks-cnb   1m
```

### Design the build

Next, let’s create a Build to build a sample Java app on GitHub ([sample-java-app](https://github.com/buildpack/sample-java-app.git)) using the build template. Create `build.yaml` file:

```yaml
apiVersion: build.knative.dev/v1alpha1  
kind: Build  
metadata:  
  name: buildtemplate-buildpack-sample-java-app-gcr  
spec:  
  source:  
    git:  
      url: [https://github.com/buildpack/sample-java-app.git](https://github.com/buildpack/sample-java-app.git)  
      revision: master  
  template:  
      name: buildpacks-cnb  
      arguments:  
      - name: IMAGE  
        value: gcr.io/knative-atamel/sample-java-app:buildpack
```

One thing you’ll notice is that the `sample-java-app` does not define a `Dockerfile`. Buildpacks will use its auto-detection to build the image and Knative will push it to the location specified in `IMAGE` argument (which is Google Container Registry in this case).

### Run the build

We can finally run the build:

```sh
kubectl apply -f build.yaml
```

After a few minutes, check that the build is succeeded:

```sh
kubectl get build

NAME                                          SUCCEEDED
buildtemplate-buildpack-sample-java-app-gcr    True
```

At this point, you should see the image pushed to Google Container Registry:

![](/img/2019/1__xGUemtlwcFlXCgvneo3OOg.png)

Knative Build with Buildpacks is a great combination for building apps at a higher abstraction level compared to Dockerfiles!