Ability to remove container locally

tomtaylor commented 6 years ago

It would be helpful to have the ability to remove a container that you've pushed to a local device.

pimterry commented 6 years ago

We can do this without too much trouble I think. I'm curious about the use case though - why do you need to manually remove containers from the device?

tomtaylor commented 6 years ago

Thanks. I pushed a local app with the wrong name and then ended up with two on the device.

On 16 Jan 2018, at 10:42, Tim Perry notifications@github.com wrote:

We can do this without too much trouble I think. I'm curious about the use case though - why do you need to manually remove containers from the device?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

pimterry commented 6 years ago

There is a local stop command - I don't think that actually removes the container, but it will let you stop the 2nd app, which will stop it actually breaking things. Would that solve your issue? Arguably local stop could have a --remove option or a separate local rm command I suppose.

Also, in recent CLI installs you shouldn't get prompted for an app name by default at all (https://github.com/resin-io-modules/resin-sync/pull/143), so this shouldn't happen unless you're explicitly providing a name. Are you manually setting a name? I'd love to know why if so, as I was starting to think about removing that functionality entirely.

tomtaylor commented 6 years ago

Thanks, that would work. I was worried stopped containers will start again at boot time. And it felt like a waste of disk space that I could use for my app’s cache.

On 16 Jan 2018, at 12:32, Tim Perry notifications@github.com wrote:

There is a local stop command - I don't think that actually removes the container, but it will let you stop the 2nd app, which will stop it actually breaking things. Would that solve your issue? Arguably local stop could have a --remove option or a separate local rm command I suppose.

Also, in recent CLI installs you shouldn't get prompted for an app name by default at all (resin-io-modules/resin-sync#143), so this shouldn't happen unless you're explicitly providing a name. Are you manually setting a name? I'd love to know why if so, as I was starting to think about removing that functionality entirely.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

zrzka commented 6 years ago

I'd appreciate this as well. I end up with a container hell on one of my devices ...

It's part of the fleet (development mode), whenever I push new version to master, it's installed on this device
I initially deployed application as local-app
Then I renamed it to local-rust-thermometer

... and now imagine that I'm going to restart RPi. All these images are fighting for one resource (X.org & RPi display). And the wrong one always won :)

I can stop main on the dashboard, that's fine. But what with the old local-app. I'd like to trash it completely and have no idea how.

Also I'd totally remove ability to name your container. Just call it local-app and that's it, all these issues gone :)

 2018-06-29 14:31:34 ⌚  Zrzka in ~/Work/rust-thermometer
± |master → origin ↑7 U:3 ?:1 ✗| → sudo resin local stop
Reporting discovered devices
? select a device cae15d3.local (10.11.12.130)
? Select a container /local-rust-thermometer (4ad1d341023)

 2018-06-29 14:31:49 ⌚  Zrzka in ~/Work/rust-thermometer
± |master → origin ↑7 U:3 ?:1 ✗| → sudo resin local stop
Reporting discovered devices
? select a device cae15d3.local (10.11.12.130)
? Select a container /main_340107_522929 (ba7cb7d3a3b)

 2018-06-29 14:32:05 ⌚  Zrzka in ~/Work/rust-thermometer
± |master → origin ↑7 U:3 ?:1 ✗| → sudo resin local stop
Reporting discovered devices
? select a device cae15d3.local (10.11.12.130)
? Select a container /local-app (bcc22eac5fd)

 2018-06-29 14:32:22 ⌚  Zrzka in ~/Work/rust-thermometer
± |master → origin ↑7 U:3 ?:1 ✗| →

pimterry commented 6 years ago

@zrzka how did you rename the deployed application? I agree you shouldn't need to do that, but we don't have a command to do that anyway.

You also shouldn't end up with your device running a local app & a git pushed app at the same time. Did you enable local mode in the dashboard? If so, that should stop the git pushed app entirely.

If you do get into a messy state, and want to manually clear up containers on the device, you can manually manage them by either:

Setting DOCKER_HOST locally to point to the device (development devices expose their docker port over the network, which is how local mode works), and then run any docker commands you like directly to manage it
SSHing into the host OS of the device (from the dashboard or CLI), and running any docker commands you like there directly (but with balena instead of docker in the command itself, e.g. balena ps).

zrzka commented 6 years ago

@pimterry sorry for my ignorance, I'm experimenting with resin just for couple of days.

1) Quite easily, removed .resin-sync.yml (as root) and run local push with different application name.

2) I didn't enable local mode, just development mode. Didn't know this. Thanks for pointing this out. Enabled.

3) Also thanks for pointing out balena, all containers stopped, images removed, device rebooted and I'm happy now!

pimterry commented 6 years ago

I'd forgotten about the app name parameter for local push, you're right, we should drop that. I've added a separate issue to track it: https://github.com/resin-io/resin-cli/issues/912

Ah, yes - development mode for images just affects what features they support, not the current behaviour of the device itself.

No problem at all about not being familiar with this yet, everybody starts like that! Let us know if you have any other questions :smiley:. In general (unless it's a well-defined CLI-specific issue) the forums is the place to go: http://forums.resin.io

jeffreygnatek commented 5 years ago

This would be very helpful, we have accidentally pushed containers to the wrong device locally and needed to remove them.

mariusmarais commented 5 years ago

Workaround I use is to --force-build, wait for the container to be removed, and then interrupt the process before the new build is done. 🤷‍♂

pdcastro commented 4 years ago

In CLI v11, the "live push" feature is enabled by default with the balena push <ip-address> command (see also: Deploy to your Fleet documentation), and the local push and local stop commands were removed.

In case this helps, a manual but powerful way of managing containers in a device in local mode* is to issue commands to balenaEngine (balena's port of Docker) directly. Open a ssh prompt to the device with either balena ssh or plain ssh, then issue commands like balena-engine ps and balena-engine rm -f. Example:

$ balena ssh 192.168.0.20
Last login: Fri Nov 22 12:42:59 2019 from 192.168.0.17

root@5d3ffbf:~# balena-engine ps
CONTAINER ID        IMAGE                               COMMAND                  CREATED             STATUS                PORTS               NAMES
c4809e009f96        7406c763a566                        "/bin/bash -c 'for (…"   15 hours ago        Up 15 hours                               main_1_1
0b0077f80419        balena/armv7hf-supervisor:v10.2.2   "./entry.sh"             6 weeks ago         Up 2 days (healthy)                       resin_supervisor

root@5d3ffbf:~# balena-engine rm -f main_1_1
main_1_1

balena-engine accepts the same commands and arguments as the docker client, so it's worth learning about it!

* Local mode is important because, otherwise, the balena supervisor automatically manages the containers and if you manually removed and started some containers, the supervisor would fight you and undo your manual actions. :-)

nishaad78 commented 4 years ago

I ended up with multiple containers running after pushing them locally using a docker compose file.

It would be nice to have a way to teardown everything that was orchestrated with my local push.

balena-io / balena-cli

Ability to remove container locally #757