Is it intended to use Kamal 2 from WITHIN the devcontainer?

I’m trying to setup a new vanilla Rails edge (8.0.0.beta1) app with --devcontainer which I wanna deploy to a VPS with Kamal 2. Now, I have a hard time figuring out if it’s intended to indeed run the kamal deployment commands from WITHIN the devcontainer - or if this should somehow be done from the outside? E.g. when trying to run bin/kamal setup from within the devcontainer in VS code terminal, then I get:

vscode ➜ /workspaces/wine_club (main) $ bin/kamal setup
  INFO [febaf013] Running /usr/bin/env mkdir -p .kamal on [188.245.192.142](http://my-server-address.com)
  INFO [febaf013] Finished in 1.387 seconds with exit status 0 (successful).
Acquiring the deploy lock...
Ensure Docker is installed...
  INFO [958301b5] Running docker -v on my-server-address.com
  INFO [958301b5] Finished in 0.157 seconds with exit status 0 (successful).
Log into image registry...
  INFO [72667841] Running docker login -u [REDACTED] -p [REDACTED] as vscode@localhost
  Finished all in 0.0 seconds
Releasing the deploy lock...
  Finished all in 1.9 seconds
  ERROR (SSHKit::Command::Failed): docker exit status: 32512
docker stdout: Nothing written
docker stderr: sh: 1: docker: not found

Which indicates to me that kamal needs docker to installed INSIDE the devcontainer - which it’s not by default :upside_down_face: which again made me think, that this might not be intended use? But if it is, how do you then recommend to get the approach going?

1 Like

Running Docker inside a container comes with performance and/or security considerations, so I’m not sure if it makes sense for it to be the default. Maybe.

Adding either the ghcr.io/devcontainers/features/docker-in-docker:2 or ghcr.io/devcontainers/features/docker-outside-of-docker:1 feature to your devcontainer.json allows you to build Docker images inside the devcontainer.

This will significantly increase the container build time (at least it did for me).

It would be nice if Kamal worked out of the box in devcontainers.

I think ghcr.io/devcontainers/features/docker-in-docker:2 does not run in privileged mode, as the documentation says it’s independent of the host, so maybe it’s a safe default. However, I’m not sure, as I don’t use devcontainers.

Using ghcr.io/devcontainers/features/docker-outside-of-docker:1 instead, exposes the host Docker socket, making it more performant but with security implications.

1 Like

Thanks for the reply. I wonder what the “official” Rails recommendations are on this point? I will take the conversation here too: Missing documentation on intended use of Devcontainers and Kamal along side · Issue #53294 · rails/rails · GitHub

I’m at the same point. After thinking a bit about the requirement of being able to run kamal from within the devcontainer I somehow feel that this could be not the best way of deploying an app.

Having kamal inside the devcontainer is useful to init etc. - but the deployment should be carried out externally, e.g. by GitHub actions. At least that’s the way I try to go now.

No, Kamal 2 is not intended to be used from within the devcontainer. It is typically run outside the devcontainer for optimal performance.

So, what would you say the intended way is then, in a simple local setup on a Mac?

The benefits of using devcontainers to seperate environments and not having to deal with installing version managers for ruby, gems and others directly on the OS, kind of vanishes, if we at the end have to do a ruby and bundle install of Kamal natively on the OS anyway in order to deploy… :upside_down_face:

Curious how others are dealing with this in a clean simple way…?

The intended way is the way that is implemented in the framework. Using kamal inside the dev container. The security concerns are not valid here. It is your development machine. In the same way you should not run random commands from the internet in your terminal, you should not run random commands of the internet in the dev container. There’re is not reason to hide the docker runtime from the dev container

Thanks for the reply @rafaelfranca - my above comment was targeted to @nickfreedy 's post saying that it was not intended to use Kamal inside the devcontainer :blush: - so I hear you say the opposite…