What's te difference between kamal deploy and kamal redeploy?

[fabriciocarboni]

https://kamal-deploy.org/docs/commands/deploy/
https://kamal-deploy.org/docs/commands/redeploy/

Every time kamal deploy i got the error but the deploy is done effectivelly.

ERROR (SSHKit::Command::Failed): Exception while executing on host xxxxxxxx: docker exit status: 1
docker stdout: Nothing written
docker stderr: Error response from daemon: No such container: 44b45b636e28
Error response from daemon: removal of container 93835d6407ef is already in progress

However if I do kamal redeploy the error does not appear and also the deploy is done.

running docke ps -a on the server I saw 5 containers with Exited status and none of the containers mentioned in the error is there. I remember that I have prunned some images mannualy last week. I wonder if kamal checks and keep auditing/tracking the containers ID to know when to prune them at given time.

But if it's the case how to normalize things? If there's no solution the only way I see is remove everything from server even the .kamal directory and run kamal setup again.

[Ecno92]

kamal redeploy only updates the app, but does not setup the proxy.
kamal deploy does setup the proxy and update the app.

kamal setup does what deploy does, but before doing so it also assures Docker is installed and accessories are booted.

If you check out the source of lib/kamal/cli/main.rb then you get an idea of what is being done.

Hopefully checking out the source of kamal helps you to identify why your environment is in such a weird state.

What I remember from similar issues is that it might help to check the logs of the failed container and fix the root cause. Finding the container which failed can be done on the host by executing docker ps -a, then you can see the logs by executing docker logs NAME_OF_CONTAINER

[webmonch]

is it safe to run each of commands multiple times?

[Cosmo]

I ran into the same issue and only noticed after getting a disk-full alert on the VM.
Investigating showed that old Docker images weren't being pruned.

In my case, the problem was that I used the IP address in one place and the DNS hostname in another, even though both pointed to the same machine.

Before:

servers:
  web:
    - 17.172.224.47
    
accessories:
  coturn:
    image: coturn/coturn
    host: example.germanywestcentral.cloudapp.azure.com

After:

servers:
  web:
    - example.germanywestcentral.cloudapp.azure.com
    
accessories:
  coturn:
    image: coturn/coturn
    host: example.germanywestcentral.cloudapp.azure.com

Once I unified the host definition, the prune step stopped erroring and old images were cleaned up correctly.

Hopefully this saves someone else some debugging time.