To mitigate potential security risks, ContainerOS prevents users from directly logging on to the system for untraceable operations. If you need to log on to an instance for maintenance, ContainerOS provides a dedicated administrative container for non-routine tasks such as troubleshooting and package installation. This topic describes how to perform common operations on administrative containers, such as logging on, starting, stopping, restarting, and querying their status.
This topic applies only to nodes that are not in Auto Mode.
ContainerOS node maintenance methods
|
The administrative container includes more software packages than the host environment and lets you install additional packages with the YUM package manager. From the container, you can view system processes, networks, and configurations. It also provides a dedicated command to access the host, which is equivalent to connecting to the instance via Workbench, SSH, or VNC.
|
|
In ContainerOS 3.5 and later, the shell is removed from the host environment. Refer to the following table to select a maintenance method for your ContainerOS nodes.
|
Method
|
ContainerOS 3.5 and later
|
ContainerOS earlier than 3.5
|
|
Log on to the administrative container
|
|
-
An SSH key pair must be bound to the instance.
When you create a node pool, you must set the logon credential to a key pair. For more information, see Create and manage node pools.
For existing node pools, you can also bind an SSH key pair to an instance. For more information, see Bind an SSH key pair.
-
Log on to the host by using Workbench (password-free logon only).
-
Run sudo lifseacli container start to start the administrative container.
-
Log on by using SSH.
By default, the SSH service (sshd) is disabled on the host.
|
|
Log on to the host
|
After you log on to the administrative container, run the sudo superman command.
|
|
You can also use the kubectl debug command to maintain ContainerOS nodes.
Logon methods for ContainerOS 3.5 and later
|
Category
|
Workbench (password-free logon only)
|
VNC logon
|
|
Prerequisites
|
None.
The Cloud Assistant agent is pre-installed in the administrative container. You do not need to install it manually.
|
VNC logon requires password authentication. You must first set a logon password for the administrative container via a password-free Workbench session.
|
|
Procedure
|
Log on to the ACK console. In the left navigation pane, click Clusters. On the Clusters page, click the name of your cluster. In the left navigation pane, click . -
In the Actions column of the node, choose More > Workbench Remote Access.
-
Follow the on-screen instructions to complete the password-free logon.
|
Log on to the ACK console. In the left navigation pane, click Clusters. On the Clusters page, click the name of your cluster. In the left navigation pane, click . -
In the Actions column of the node, choose More > VNC Remote Access, and follow the on-screen instructions to complete identity verification.
|
Logon methods for ContainerOS earlier than 3.5
Log on to the host
|
Category
|
Workbench (password-free logon only)
|
VNC logon
|
|
Prerequisites
|
Ensure that the node has network access to the Cloud Assistant service.
|
VNC logon requires password authentication. You must first set a logon password for the administrative container via a password-free Workbench session.
|
|
Procedure
|
Log on to the ACK console. In the left navigation pane, click Clusters. On the Clusters page, click the name of your cluster. In the left navigation pane, click . -
In the Actions column of the node, choose More > Workbench Remote Access.
|
Log on to the ACK console. In the left navigation pane, click Clusters. On the Clusters page, click the name of your cluster. In the left navigation pane, click . -
In the Actions column of the node, choose More > VNC Remote Access, and follow the on-screen instructions to complete identity verification.
|
Administrative container logon
Prerequisites
-
When you create a node pool, you must set the logon credential to a key pair. For more information, see Create and manage node pools.
For existing node pools, you can also bind an SSH key pair to an instance. For more information, see Bind an SSH key pair.
-
The Cloud Assistant agent must be installed. For more information, see Install the Cloud Assistant Agent.
-
Port 22 must be allowed in your security group rules. For more information, see Manage security group rules.
-
Password-free logon must be enabled for the ECS instance.
On the Remote Connection via Session Management page, click the Password-free Logon tab and confirm that session management is enabled for all regions. The toggle must be in the enabled (green) state.
Access the host environment
-
Log on to the ECS console and navigate to the Command panel of Cloud Assistant. For more information, see Create and run commands.
-
In Cloud Assistant, run the following command to start the administrative container:
sudo lifseacli container start
Expected output:
Downloading docker image...
Successfully downloaded docker image
Successfully start admin container!
The output indicates that Cloud Assistant successfully started the administrative container.
-
From a terminal on your local machine, run the following command to log on to the administrative container with the specified private key.
Note
-
Replace <ssh-private-key.pem> with the private key of the key pair that is bound to the instance. Replace <instance-ip> with the IP address of the instance.
-
You can also log on as admin by using Workbench. Use the private key from the key pair that is bound to the instance. Ensure that port 22 is open on your instance.
ssh -i <ssh-private-key.pem> admin@<instance-ip>
After you log on to the administrative container, the host's root file system is mounted as read-only to the /.lifsea/rootfs directory in the administrative container. Use this mount to find system information and configurations.
$ssh -i mainxt.pem admin@47.99.45.171
Welcome to LifseaOS maintenance container!
This container is based on Alibaba Cloud Linux 3, therefore most things
should behave the same as a Alibaba Cloud Linux 3 VM or container.
Some common tools are pre-installed for debug purpose and you can install
any tools you want through yum.
Also you can access the LifseaOS host root filesystem (see /.lifsea/rootfs)
within the container.
If you want to place yourself in a real LifseaOS host environment, a tool
named "superman" (`sudo superman`) is provided. Once run, you will go
inside the LifseaOS host's rootfs with a root shell.
Enjoy!
[admin@iZbp1inxxxxtziZ ~]$
-
Run the following command to access the host environment from the administrative container.
-
Run the ls command to list the available system commands.
[root@xxxs9Z /]# ls
bin boot dev etc home lib lib64 media mnt opt ostree proc root run sbin srv sys sysroot tmp usr var
Only a limited number of system commands are available in the host environment.
Manage the administrative container
After entering the host environment, run exit to return to the administrative container. Run exit again to log out. The administrative container continues to run, allowing you to reconnect via SSH, or use commands to stop, restart, or delete it.
|
Actions
|
Description
|
|
Stop the administrative container
|
sudo lifseacli container stop
|
|
Restart the administrative container
|
If you bind or unbind a key pair after you start the administrative container, you must restart the container for the change to take effect. sudo lifseacli container restart
|
|
Delete the administrative container
|
sudo lifseacli container rm
Important
When you delete the administrative container, any software you installed or files you saved in it are also destroyed. If you start an administrative container again, a new, clean environment is created. We recommend that you do not store critical data in the administrative container.
|
|
Query the status of the administrative container
|
sudo lifseacli container status
|
FAQ
The UNPROTECTED PRIVATE KEY FILE! error
Symptoms
You receive the following error:
$ssh -i manxi.pem admin@47
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'manxi.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "manxi.pem": bad permissions
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Cause
The permissions on the private key file are too permissive.
Solution
Run the chmod 400 <ssh-private-key.pem> command to change the permissions of the private key file to 400. Replace <ssh-private-key.pem> with the name of your private key file.