This change addresses a long-standing issue in rST documentation imported from XML. That import process added backslash escapes in front of various characters. The three most common being '(', ')', and '_'. These instances are removed. Signed-off-by: Ron Stone <ronald.stone@windriver.com> Change-Id: Id43a9337ffcd505ccbdf072d7b29afdb5d2c997e
6.8 KiB
Use Container-backed Remote CLIs and Clients
Remote platform can be used in any shell after sourcing the generated remote CLI/client RC file. This RC file sets up the required environment variables and aliases for the remote commands.
Consider adding the following command to your .login or shell rc file, such that your shells will automatically be initialized with the environment variables and aliases for the remote commands.
Otherwise, execute it before proceeding:
root@myclient:/home/user/remote_cli_wd# source remote_client_platform.sh
You must have completed the configuration steps described in
Configuring Container-backed Remote CLIs and Clients <security-configure-container-backed-remote-clis-and-clients>
before proceeding.If you specified repositories that require authentication when configuring the container-backed remote , you must perform a
docker login
to that repository before using remote for the first time
For simple StarlingX
system
and Kuberneteskubectl
commands:Note
The first usage of a remote command will be slow as it requires that the docker image supporting the remote CLIs/clients be pulled from the remote registry.
root@myclient:/home/user/remote_cli_wd# system host-list +----+--------------+-------------+----------------+-------------+--------------+ | id | hostname | personality | administrative | operational | availability | +----+--------------+-------------+----------------+-------------+--------------+ | 1 | controller-0 | controller | unlocked | enabled | available | | 2 | controller-1 | controller | unlocked | enabled | available | | 3 | compute-0 | worker | unlocked | enabled | available | | 4 | compute-1 | worker | unlocked | enabled | available | +----+--------------+-------------+----------------+-------------+--------------+ root@myclient:/home/user/remote_cli_wd# kubectl -n kube-system get pods NAME READY STATUS RESTARTS AGE calico-kube-controllers-767467f9cf-wtvmr 1/1 Running 1 3d2h calico-node-j544l 1/1 Running 1 3d calico-node-ngmxt 1/1 Running 1 3d1h calico-node-qtc99 1/1 Running 1 3d calico-node-x7btl 1/1 Running 4 3d2h ceph-pools-audit-1569848400-rrpjq 0/1 Completed 0 12m ceph-pools-audit-1569848700-jhv5n 0/1 Completed 0 7m26s ceph-pools-audit-1569849000-cb988 0/1 Completed 0 2m25s coredns-7cf476b5c8-5x724 1/1 Running 1 3d2h ... root@myclient:/home/user/remote_cli_wd#
Note
See the procedure for configuring the platform certificate at
install-update-the-starlingx-rest-and-web-server-certificate
.If HTTPS is enabled for the StarlingX REST API Server on the system, copy the certificate of the that issued/signed the StarlingX REST API Server's certificate to the folder
$HOME/remote_wd_cli
on the remote machine and execute commands as follows:For
system
commands:~(keystone_admin)]$ system --ca-file ca.pem host-list
For
dcmanager
commands:~(keystone_admin)]$ OS_CACERT=ca.pem ~(keystone_admin)]$ dcmanager subcloud list
Note
Some commands are designed to leave you in a shell prompt, for example:
root@myclient:/home/user/remote_cli_wd# openstack
or
root@myclient:/home/user/remote_cli_wd# kubectl exec -ti <pod_name> -- /bin/bash
In most cases, the remote will detect and handle these commands correctly. If you encounter cases that are not handled correctly, you can force-enable or disable the shell options using the <FORCE_SHELL=true> or <FORCE_NO_SHELL=true> variables before the command.
For example:
root@myclient:/home/user/remote_cli_wd# FORCE_SHELL=true kubectl exec -ti <pod_name> -- /bin/bash root@myclient:/home/user/remote_cli_wd# FORCE_NO_SHELL=true kubectl exec <pod_name> -- ls
You cannot use both variables at the same time.
If you need to run a remote command that references a local file, then that file must be copied to or created in the working directory specified in the -w option on the ./config_client.sh command.
For example:
root@myclient:/home/user# cp /<someDir>/test.yml $HOME/remote_cli_wd/test.yml root@myclient:/home/user# cd $HOME/remote_cli_wd root@myclient:/home/user/remote_cli_wd# kubectl -n kube-system create -f test.yml pod/test-pod created root@myclient:/home/user/remote_cli_wd# kubectl -n kube-system delete -f test.yml pod/test-pod deleted
For Helm commands:
% cd $HOME/remote_cli_wd
Note
When using helm, any command that requires access to a helm repository (managed locally) will require that you be in the $HOME/remote_cli_wd directory and use the --home ./.helm option. For the host local installation, it requires the users $HOME and ends up in $HOME/.config and $HOME/.cache/helm.
% helm --home ./.helm repo add bitnami https://charts.bitnami.com/bitnami % helm --home ./.helm repo update % helm --home ./.helm repo list % helm --home ./.helm search repo % helm --home ./.helm install wordpress bitnami/wordpress
Related information
Configuring Container-backed Remote CLIs and Clients
<security-configure-container-backed-remote-clis-and-clients>
Installing Kubectl and Helm Clients Directly on a Host
<security-install-kubectl-and-helm-clients-directly-on-a-host>
Configure Remote Helm v2 Client
<configure-remote-helm-client-for-non-admin-users>