How to handle more than one docker image

[rata]

Hi,

It's not clear to me after reading the README and a quick glance at the code, how can I build several images from different Dockerfiles to run in different containers in the same pod.

How is that handled?

[rata]

If there is no current plan, maybe a directory per container (and if we want to support multiple pods, maybe per pod too) inside /.k2e which has:

.k2e:
        - <pod 1>:
                     - service and replication controller yaml
                      - <container 1>
                           - Dockerfile
                           - It's crt file
                     - < container N>
       - <pod N>:
             ....

?

[ethernetdan]

@rata: So the solution I've been thinking about is supporting putting build details in the YML or JSON as a comment. A downside of that for JSON is it becomes no longer valid.

Something like:

apiVersion: v1
kind: Pod
metadata:
  name: go
spec:
  containers:
    - name: go
      image: "golang:1.6" #! build ./path/to/docker/context
      command: ["/bin/sh","-c"]

My motivation here is that I've gotten a lot of feedback that people don't want to be constrained to using a directory convention we make up. What do you think?

[rata]

Yes, I agree that forcing a directory layout is a constraint and it's better to avoid it, if possible.

I'm not sure how other tools around kubernetes are "hooking up", but it will be nice if there is a "common interface" to hook up. The annotations seem fine, maybe add some prefix to make clear it's redspread specific.

And also, not only the context but the Dockerfile (and maybe the tag for the image built?) is needed per container.

[SolarisYan]

@rata So what's the way to solve this issue?

does this

apiVersion: v1
kind: Pod
metadata:
name: go
spec:
containers:
- name: go
image: "golang:1.6" #! build ./path/to/docker/context
command: ["/bin/sh","-c"]

is avilable now?

[ethernetdan]

@rata: good idea about namespacing the comment annotation. Any suggestions on prefix? "rs_" maybe?

What about if a Dockerfile could be specified with a parameter after the context name? If none is specified, "Dockerfile" is assumed. For example:

...
containers:
    - name: go
      image: "golang:1.6" #! build ./path/to/docker/context SomeDockerfile
...

For the image name/tag I was thinking we could just use the value of the image field of Container. Thoughts?

@SolarisYan: we are still in the process of finalizing how this will work, but I think we're getting close. Your thoughts would be greatly appreciated :)