Define build strategy with Kubernetes

[surajssd]

Kubernetes by default has no container image build mechanism, so what are the ways are we gonna support it?

[surajssd]

One point I would like to add here is the builds should be generic enough that image format is supported for both container runtimes that kubernetes supports i.e. docker and rkt

[sebgoa]

you want to run kompose within a k8s cluster ?

I am not sure I get it. It is a client side tool.

[kadel]

Hmm, I'm not sure I get it either.

Only way how to do builds with Kubernetes that I can think of right now is to build image (similarly as docker-compose would) and than push it to some registry that is also accessible by targeted Kubernetes cluster.

[surajssd]

I created this issue if we wanna give a end-to-end feel on k8s we will have to decide what we do with builds, are we gonna handle image builds for user? or right now keeping it out of our scope and giving user a warning and asking them to build themselves?

Our target users are gonna be developers who use kompose + k8s running locally in minikube like env, so how are we gonna handle this?

I want views of all of you folks.

[sebgoa]

ok got it.

IMHO for now we should skip "builds" and define it as "unsupported".

Because for images to be used within a k8s cluster they would need to be uploaded to a registry as well. So it will be difficult to run out of the box with kompose. There will be manual intervention not matter what.

[surajssd]

thanks for making this clear, will wait for what @janetkuo and @ngtuna has to say then we can close this issue! :)

[janetkuo]

I agree with @Runseb 😃

[ngtuna]

I'm +1 for @Runseb

[janetkuo]

Just to be clear, I also agree with @surajssd that we should give an end-to-end feel and should support "builds" in the future.

We can push to a registry specified in a preference file. K8s provides private Docker registry addon that we can use.

[rtnpro]

With support for openshift buildconfig implemented, we are now in a position to complete the end-to-end build story by supporting local builds for kubernetes and openshift.

Below, I am documenting the local build feature.

Goal

To support build directive in a Docker Compose service for Kubernetes (and hence Openshift) by building images locally and pushing it to a registry.

Issue

Kubernetes has a registry addon to host container images privately, but it does not have a mechanism like Openshift's buildconfig to internally build images from source in an automated way and push it to the internal registry. As a result, a kompose user trying to convert a compose file with a build directive and deploy it to kubernetes will need to do the following:

• build the image locally
• push it to a registry in use by the kubernetes setup
• may need to tinker with the image names in the artifacts generated by kompose

In order to provide a good user experience to Kubernetes Kompose users, we need to automate local image build, image upload to Kuberenetes (or Openshift) accessible registry. This will also prove to be useful for Openshift as well by allowing Kompose users (developers) to deploy local code without pushing it to a public repository.

Proposed solution

• Use system's docker command to build image locally
• Use service name as image name, or use service's metadata to override it
• Pushing image to remote registry:
  • Use docker push CLI to push image
  • You can push push to a non default registry by specifying it using CLI option --target-registry
  • Kompose will not take care of logging in to remote registry. The user needs to ensure that Docker is setup/configured to push to the target registry. Refer to 1
• Use built image's name in deployment artifacts as needed, so that the user does not need to edit them manually.

[pradeepto]

@rtnpro Thank you for the proposal.
I have one question though - one of the tenet of Kompose is that the user doesn't need docker engine / CLI installed / running. This proposal assumes that Docker engine / CLI is installed and running. Is that correct?

To be clear, I am NOT against the proposal. In fact, I would like to see this done and will highly appreciate the end-to-end feature in Kompose. But just wanted to bring this though to the table so that we know what we are changing.

Looks good otherwise but I would appreciate other folks who are more knowledgeable than me.

[rtnpro]

On Mon, Jan 2, 2017 at 10:20 AM, Pradeepto Bhattacharya ***@***.***> wrote: @rtnpro Thank you for the proposal. I have one question though - one of the tenet of Kompose is that the user doesn't need docker engine / CLI installed / running. This proposal assumes that Docker engine / CLI is installed and running. Is that correct?

Yes

[kadel]

@pradeepto

I have one question though - one of the tenet of Kompose is that the user doesn't need docker engine / CLI installed / running.

If we assume that Kompose is used by developers developing containerized applications that they will need Docker anyway. (More so if they have docker-compose file with build. So I would say that Docker as requirement for supporting builds is fair.

Kompose will be still useful without Docker (it will be required only if build is used)

@rtnpro

Use service name as image name, or use service's metadata to override it

We don't need any metadata to override it.
Yes by default service name is used as image name, but it can be overridden by image field in docker-compose file.

Ff you have docker-compose file like this:

 version: '2'
 services:
   foo:
     build: .
     image: myregistry.example.com/myimage:v0.1

You don't need any additional information you have everything that you need. (Expecting that docker is already authenticated to access myregistr.example.com)

[ngtuna]

+1. I think that makes sense to have Kompose triggers the docker build, then having docker installed or not is out of kompose's scope. I suggest to define kompose label for target repository instead of flag.

[kadel]

I suggest to define kompose label for target repository instead of flag.

we don't need label for that. As repository is part of the image name and that can be set by image keyword in docker-compose file.

[ngtuna]

we don't need label for that. As repository is part of the image name and that can be set by image keyword in docker-compose file.

Yes I agree. If user doesn't set repository in the image name then we make the default to docker hub.

[surajssd]

But also consider the part where images need to be pushed to registry? Who will do that user does manually or kompose does build and push both(using docker in backend)?

[kadel]

But also consider the part where images need to be pushed to registry? Who will do that user does manually or kompose does build and push both(using docker in backend)?

Kompose will do it. It will use docker engine to do build and push.

[surajssd]

okay so we are assuming here that user will have:

• docker daemon running locally
• setup docker-registry
• docker daemon is set up to push to private registry by adding registry info in /etc/sysconfig/docker
• user is authenticated with the registry

[kadel]

docker daemon running locally

Yes, it will be usually local docker or boot2docker on mac.
Technically he need just docker client configured to connect to any docker daemon.

setup docker-registry

That is one of the options that user has. He can use some hosted registry like Docker Hub or quay.io
In case of OpenShift, it is possible to use integrated registry, if it is exposed.

docker daemon is set up to push to private registry by adding registry info in /etc/sysconfig/docker

If his registry is signed by untrusted certification authority or selfsigned, than yes.

user is authenticated with the registry

yes

But overall it is yes to your list. It is not that great UX as with just docker-compose but this is by design more complicated thing. We can do this to start with it, and than improve it if we figure out how.

[rtnpro]

Initial work pushed to #372

[rtnpro]

In case of supporting local builds for openshift, let's add an optional flag: --local-build for convert for openshift provider. By default, Openshift will use buildconfig.

[kadel]

I would probably do it other way around. As BuildConfig requires relaxed permissions on OpenShift cluster that are not in default configurations. I think that we should use local build as default for OpenShift.

…

On Wed, Jan 11, 2017 at 1:58 PM, Ratnadeep Debnath ***@***.*** > wrote: In case of supporting local builds for openshift, let's add an optional flag: --local-build for convert for openshift provider. By default, Openshift will use buildconfig. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#97 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADfdpJEWRSr9dbV_v_G_nekGyuFp_rIks5rRNIDgaJpZM4JhUBg> .

[cdrage]

#521 Has been merged! 🎉 🎉 🎉 Let's close this! 👍