Kubernetes nowadays quickly outgrows Cloud Foundry. People even say containers are eating the software world. From the operator perspective the change is very much appreciated, but on the other hand there is a group which may have lost a very useful feature - a single click to run source, so called 'cf push'. Can't we do the same in Kubernetes? Nothing could be more wrong! In this presentation Adam will show how this kind of tool can be implemented - from the source code packaging, through running the temporary builder in the and using OCI buildpacks.io pack to create resulting image and finally pushing it to the docker repository, running in the Kubernetes and exposing to the world.

1. Kubernetes buildpacks – from
souce code to running OCI
containers in a single
command
ADAM KOZLOWSKI, Grape Up
adam.kozlowski@grapeup.com November 2019, Warsaw
www.devopsdays.pl

2. — TechnicalTeamLeaderinGrapeUp,
partofCloudboostrproject.
— CertifiedKubernetesAdministrator.
— Over6enterprisecloudnativeorKubernetesprojects,
postionfromseniordeveloper
totechnicalleader.
— DevOpsDayKrakowcommitteemember:)
About me
Clients:
Adam
Kozłowski

3. 1. What is a buildpack?
2. Cloud Foundry developer experience
3. Replicating the idea in Kubernetes
4. Buildpack stages
5. Cloud Native Buildpacks
6. Build Flow
7. Building and manifests
8. Demo!
Table of contents

4. Buildpack turns application source code
into the running application artifact.

5. Cloud Foundry developer exeprience
Cloud Foundry focuses
on running the code
in cloud as approachable
and as easy as possible

6. Can we do the same in Kubernetes?

8. Code
Grab the source code of the
application and optionally a
manifest file which describe
it’s dependencies and send
it to the builder.
Buildpack stages
Build
Use the buildpack(s) to
build a code and create an
artifact result. It may be a
docker image, archive file or
just executable depending
on the target platform.
Deploy
Deploy the artifact to the
target platform or
repository.
Run
Run the artifact from the
repository or blobstore with
default configuration or
optionally with parameters
and dependencies specified
in the first step.
Detect & Analyse
Check the source code
agains registered buildpacks
to select best match. For
example requirements.txt
file suggests Python and
package.json NodeJS

9. Cloud Native Buildpacks: https://buildpacks.io
Buildpacks.io Advantages
— Support for Cloud Foundry
builders, Heroku builders and
any OCI compliant builder,
— Easy to use and small CLI,
— OCI compliant – should run on
any platform.
Disadvantages
— Poor documentation,
— No live build possibility,
— Building without cache (on
CI/CD) can be very slow,
— Requirements for pack CLI.
Easy to use CLI
Supports multiple languages out
of the box – Java, Python, Go,
NodeJS, .NET Core, PHP
OCI compliant

10. Buildflow
lifecycle
buildpack python
buildpack pip
builpack …
builderSource Code
Docker registry
Target cluster
run

11. ?
Builder image
Based on Docker In Docker image with pack CLI installed

12. Building process
— Run builder image
— Push code to the container using kubectl cp
— Run docker in docker
— Execute pack inside source code directory
— Push result to image repository
— kubectl run the image in the cluster
— kubectl expose the deployment

13. Manifest template
— To mimic the behavior of gorouter the
application has to be exposed and
available externally
— The ingress object is one of the few
kubernetesm resources which cannot be
created without a template
— So we create the template

14. Demo!

15. Questions?

16. ADAM KOZLOWSKI, Grape Up
adam.kozlowski@grapeup.com
I'm waiting
for your feedback!
You can rate speakers and lectures using
our official conference app