Containers

Containers

The containers on a server with Docker, in a tab of their own: a bit like Portainer, but inside Cablebag and over the SSH login you already have. New in 0.19.0; stacks, templates and moving stacks in 0.20.0.

Opening it

• Right-click an SSH session in the tree and choose Containers. Servers where Cablebag found Docker before say "Docker" next to it.
• Or right-click an open SSH tab: Containers on this server.
• In the search box (Ctrl+K), servers that have Docker show as Containers on ....

The tab makes its own SSH connection with the session's login, jump hosts and network, and asks Docker there with the docker command. No Docker port is opened on the server. While the tab is on screen it looks again every 10 seconds; Refresh looks straight away.

The list and the details

On the left, every container on one line: a dot, the name, and how long it runs. When something is wrong, that place says what instead: unhealthy, restarting, 23 restarts, stopped. The heading says how many need a look.

• A project with more than one container groups them under the project's name (with Portainer when Portainer made it); a project of one container is one line.
• Needs a look and Stopped show only those; the box next to them finds a container, image or project.
• Stacks in ~/stacks that have no containers now show under Not running.
• Up and down walk the list.

On the right, the container you picked:

• its state in words, and buttons Logs, Shell, Restart, Stop (or Start) and Pause;
• Ask the assistant (see below);
• its image, its web ports as Open port ... (in a web tab: https for 443, 8443 and 9443, http for the rest), and ports only used inside;
• its project, the compose file and what you can do with the project.

Compose files

Docker remembers for every container started with Docker Compose which project it belongs to, in which folder and with which compose files. Cablebag shows that file with the project, so you no longer need to remember where it was.

• A file on the server opens in Cablebag's editor (see Remote files and editing): before anything is written you see the changes, and the server keeps a .bak. Then:
  • Apply the compose file runs docker compose up -d in the project's folder, after your yes;
  • Pull new images downloads newer images (apply the compose file afterwards to use them);
  • Restart all and Stop all (after your yes) for a project of more than one container;
  • Remove stack takes its containers away (after your yes); its volumes and files stay.
• A stack made in Portainer is marked Portainer. Portainer keeps its compose files inside its own data; Cablebag shows the file read-only, with Open in Portainer. Change and redeploy such a stack in Portainer, so Portainer knows about it. For a server Portainer manages through its agent (a NAS, for example), Cablebag reads the file from the Portainer on another open server.

Stacks of your own

New stack at the top opens a window with templates on the left and on the right:

• Name: the stack goes to ~/stacks/<name> on the server (small letters, digits, - and _);
• Compose file and an optional .env;
• one field per blank: write {{name}} in the file for something to fill in when the stack is made, as in macros. A blank named like a password hides what you type.

Create and start writes the files (readable only by your login, as they may hold passwords) and runs docker compose up -d. A stack that already exists is never overwritten. Save as template keeps the file as a template instead.

Templates

A template is a compose file (and .env) with blanks. Make one:

• from the New stack window, Save as template;
• from any running project, also one made in Portainer: pick a container and Save as template;
• from a container started without Compose: Cablebag writes the compose file for it from what Docker knows (image, ports, environment, folders, volumes, restart policy).

Values of settings named like a password, token or key become blanks, so a template never holds a secret. Templates travel with Sync. Delete one with the bin next to it in the New stack window.

Moving a stack to another server

Move to another server... on a project. Open the other server's Containers first (the window has a choice to open one): Cablebag uses that connection.

Check the move first. It looks at:

• Folders. Every folder the stack uses is looked up on the shared storage both servers use (NFS or SMB): where it is on the NAS, and where that NAS folder is mounted on the other server. A mount under another name, a deeper or shallower mount, and the NAS itself (where the folder is local, /volume2/Docker/..., also as /share/Docker/...) are all found. The paths in the compose file are changed for the other server, also inside ${VAR:-/path} defaults.
• What cannot move by itself: folders and Docker volumes only on this server (copy them first), and a NAS folder the other server does not mount.
• Ports already in use there, container names that would clash, networks that do not exist there, a different processor, private registries the other server is not logged in to, devices and host networking.
• Images are pinned to the exact version running now, so the other server does not pull a newer one.

The compose file as it will go is shown, and you can still change it. With a problem in the list, Move needs Move anyway ticked.

Move then:

1. stops the stack here (stopped, not removed: never both at once on the same data);
2. writes it to ~/stacks/<name> there and starts it;
3. waits until every container runs and none is unhealthy;
4. when it does not come up healthy, removes it there and starts it here again.

Every move (and every roll-back) is kept in a list on this PC; the window shows the last ones for that stack. A stack made in Portainer: remove it in Portainer after the move.

Logs and a shell

• Logs opens a terminal tab with docker logs -f for the container: the last 300 lines, then whatever comes. Ctrl+C ends it and the tab closes.
• Shell opens a terminal tab inside the running container, with bash when the container has it, sh otherwise. exit closes the tab.

Both are ordinary SSH tabs on the same server, so copy, find and the assistant work as in any terminal.

Ask the assistant

Ask the assistant gives the assistant the container's state, where it comes from (project, compose file) and its last 100 log lines, with secrets hidden. When something is wrong the button asks the question already: Why does it keep restarting?, Why is it unhealthy?, Why did it stop? It can look further with commands that only read; a restart or a change waits for your yes, as always. It needs an AI host under Settings, Assistant.

Who may use Docker

Cablebag uses Docker as the login of the session. When that login may not use Docker:

• with sudo that needs no password, Cablebag goes through sudo, and the tab says so;
• with sudo that wants a password (a NAS, often), the tab offers Use sudo with your password. The password is the login's own (not root's). It comes from the session's vault login, or Cablebag asks once and keeps it in memory while the tab is open. Cancel, or a password sudo does not take, goes back to the button;
• otherwise add the user to the docker group (sudo usermod -aG docker <user>, then log in again) or log in as root. Being in the docker group is as good as being root on that server.