Send arguments to a Job

11/25/2018

I have a docker Image that basically runs a one time script. That scripts takes 3 arguments. My docker file is

FROM <some image>

ARG URL
ARG USER
ARG PASSWORD

RUN apt update && apt install curl -y

COPY register.sh .
RUN chmod u+x register.sh

CMD ["sh", "-c", "./register.sh $URL $USER $PASSWORD"]

When I spin up the contianer using docker run -e URL=someUrl -e USER=someUser -e PASSWORD=somePassword -itd <IMAGE_ID> it works perfectly fine.

Now I want to deploy this as a job.

My basic Job looks like:

apiVersion: batch/v1
kind: Job
metadata:
  name: register
spec:
  template:
    spec:
      containers:
      - name: register
        image: registeration:1.0
        args: ["someUrl", "someUser", "somePassword"]
      restartPolicy: Never
  backoffLimit: 4

But this the pod errors out on

Error: failed to start container "register": Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"someUrl\": executable file not found in $PATH"

Looks like it is taking my args as commands and trying to execute them. Is that correct ? What can I do to fix this ?

--
kubernetes
kubernetes-jobs

2 Answers

11/25/2018

Use:

args: ["sh", "-c", "./register.sh someUrl someUser somePassword"]
-- Shudipta Sharma
Source: StackOverflow

11/25/2018

In the Dockerfile as you've written it, two things happen:

  1. The URL, username, and password are fixed in the image. Anyone who can get the image can run docker history and see them in plain text.

  2. The container startup doesn't take any arguments; it just runs the single command with its fixed set of arguments.

Especially since you're planning to pass these arguments in at execution time, I wouldn't bother trying to include them in the image. I'd reduce the Dockerfile to:

FROM ubuntu:18.04
RUN apt update \
 && DEBIAN_FRONTEND=noninteractive \
    apt install --assume-yes --no-install-recommends \
      curl
COPY register.sh /usr/bin
RUN chmod u+x /usr/bin/register.sh
ENTRYPOINT ["register.sh"]

When you launch it, the Kubernetes args: get passed as command-line parameters to the entrypoint. (It is the same thing as the Docker Compose command: and the free-form command at the end of a plain docker run command.) Making the script be the container entrypoint will make your Kubernetes YAML work the way you expect.

In general I prefer using CMD to ENTRYPOINT. (Among other things, it makes it easier to docker run --rm -it ... /bin/sh to debug your image build.) If you do that, then the Kubernetes args: need to include the name of the script it's running:

args: ["./register.sh", "someUrl", "someUser", "somePassword"]
-- David Maze
Source: StackOverflow