Use args instead of command

[matjack1]

Using args instead of command replaces Docker CMD instead of ENTRYPOINT.

This is counterintuitive, as I found out here: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#define-a-command-and-arguments-when-you-create-a-pod

The command field corresponds to ENTRYPOINT, and the args field corresponds to CMD in some container runtimes.

In my case it's actually working that way. So if we use args it works fine and doesn't override my ENTRYPOINT, which I assume is normally expected.

[collimarco]

This is the intended behavior. We use CMD because you can override it.

For example, if you use Rails you will have a Dockerfile that ends like this:

...

CMD ["./bin/rails", "server", "-p", "8080"]

The default action is to run the web server. It acts like a placeholder.

However you can specify the actual commands from the Cuberfile, for example:

proc :web, 'bundle exec puma', scale: 3  # run the web server
proc :worker, 'bundle exec sidekiq', scale: 5 # run background jobs

The Docker image is the same, but the containers are started with different commands.

Then you can also start a different CMD manually (that overrides the default CMD in the Dockerfile) when you need that (e.g. for debugging). For example, if you need to start an interactive Rails console in production you can run:

cuber run rails console

[matjack1]

I agree. The problem is that setting "command" in Kubernetes you are overriding the ENTRYPOINT in my case, so my ENTRYPOINT was ignored.

If you don't normally set an ENTRYPOINT, then you don't notice the difference. Do you have an ENTRYPOINT and works for you? I'm using Kubernetes on AWS, maybe it's something specific to that environment?

[collimarco]

Thanks for pointing this out!

You are right, Kubernetes command overrides both Docker ENTRYPOINT and CMD.

Actually we don't use ENTRYPOINT at all.

For Rails, for example, the only reason to use ENTRYPOINT is for database migrations, however we already use a better strategy with the Cuber migrate command:

migrate 'bundle exec rails db:migrate', check: 'bundle exec rake db:abort_if_pending_migrations'

However also not overriding ENTRYPOINT (your proposal) has some drawbacks:

• more difficult to understand the entire command that is executed (because a part of the command is in Docker ENTRYPOINT and another part is defined in Kubernetes args)
• you always get an execution of ENTRYPOINT, which may be something limiting in some circumstances (e.g. if you want to launch a simple debugging pod with cuber run bash and the pod doesn't start because there is a problem with migrations in the ENTRYPOINT and you cannot bypass that... that would not be fun)

[collimarco]

Another note: if you need to run a more complex shell script, that you currently run as an ENTRYPOINT, you can always use something like this:

proc :web, '/path/to/myscript.sh', scale: 3

In this case the script should include both the entrypoint code and the final command.

[matjack1]

Thank you for your perspective on this.

I still think that the ENTRYPOINT can be useful as it's a common pattern to set up things that should be run on a container by default and from what I've read cuber run should bypass the entrypoint, so it should be safe.

Nonetheless also the script approach is fine and for the migrations/preparation of the DB we can run a command and restart the pods, that's fine.

I'm going to close this.