opensource/podman
1
0
Fork 0
mirror of https://github.com/containers/podman.git synced 2025-05-20 16:47:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

Cleanup tutorials

Browse Source 
Inspired by @kannkyo PR.

Eliminate sudo when commands will work fine in rootless mode.

Make all commands in tutorials easily cut and pastable, by eliminating
$ and > symbols.

This should make them all consistant agross different tutorials.

Also make all systemctl enable calls use the --now option.

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
This commit is contained in:
Daniel J Walsh
2020-11-16 11:59:52 -05:00
parent d30f9ae8b6
commit d200801152
5 changed files with 36 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/tutorials/image_signing.md
View File

@ -34,7 +34,7 @@ Now let’s assume that we run a container registry. For example we could simply
start one on our local machine:
```bash
> sudo podman run -d -p 5000:5000 docker.io/registry
sudo podman run -d -p 5000:5000 docker.io/registry
```
The registry does not know anything about image signing, it just provides the remote
@ -44,11 +44,11 @@ have to take care of how to distribute the signatures.
Let’s choose a standard `alpine` image for our signing experiment:
```bash
> sudo podman pull docker://docker.io/alpine:latest
sudo podman pull docker://docker.io/alpine:latest
```
```bash
> sudo podman images alpine
sudo podman images alpine
REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/library/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB
```
@ -56,11 +56,11 @@ docker.io/library/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB
Now we can re-tag the image to point it to our local registry:
```bash
> sudo podman tag alpine localhost:5000/alpine
sudo podman tag alpine localhost:5000/alpine
```
```bash
> sudo podman images alpine
sudo podman images alpine
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost:5000/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB
docker.io/library/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB
@ -84,7 +84,7 @@ We can see that we have two signature stores configured:
Now, let’s push and sign the image:
```bash
> sudo -E GNUPGHOME=$HOME/.gnupg \
sudo -E GNUPGHOME=$HOME/.gnupg \
podman push \
--tls-verify=false \
--sign-by sgrunert@suse.com \
@ -97,7 +97,7 @@ If we now take a look at the systems signature storage, then we see that there
is a new signature available, which was caused by the image push:
```bash
> sudo ls /var/lib/containers/sigstore
sudo ls /var/lib/containers/sigstore
'alpine@sha256=e9b65ef660a3ff91d28cc50eba84f21798a6c5c39b4dd165047db49e84ae1fb9'
```
@ -107,14 +107,14 @@ The default signature store in our edited version of
the local staging signature store:
```bash
> sudo bash -c 'cd /var/lib/containers/sigstore && python3 -m http.server'
sudo bash -c 'cd /var/lib/containers/sigstore && python3 -m http.server'
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
```
Let’s remove the local images for our verification test:
```
> sudo podman rmi docker.io/alpine localhost:5000/alpine
sudo podman rmi docker.io/alpine localhost:5000/alpine
```
We have to write a policy to enforce that the signature has to be valid. This
@ -142,13 +142,13 @@ below example, copy the `"docker"` entry into the `"transports"` section of your
The `keyPath` does not exist yet, so we have to put the GPG key there:
```bash
> gpg --output /tmp/key.gpg --armor --export sgrunert@suse.com
gpg --output /tmp/key.gpg --armor --export sgrunert@suse.com
```
If we now pull the image:
```bash
> sudo podman pull --tls-verify=false localhost:5000/alpine
sudo podman pull --tls-verify=false localhost:5000/alpine
…
Storing signatures
e7d92cdc71feacf90708cb59182d0df1b911f8ae022d29e8e95d75ca6a99776a
@ -164,14 +164,14 @@ accessed:
As an counterpart example, if we specify the wrong key at `/tmp/key.gpg`:
```bash
> gpg --output /tmp/key.gpg --armor --export mail@saschagrunert.de
gpg --output /tmp/key.gpg --armor --export mail@saschagrunert.de
File '/tmp/key.gpg' exists. Overwrite? (y/N) y
```
Then a pull is not possible any more:
```bash
> sudo podman pull --tls-verify=false localhost:5000/alpine
sudo podman pull --tls-verify=false localhost:5000/alpine
Trying to pull localhost:5000/alpine...
Error: error pulling image "localhost:5000/alpine": unable to pull localhost:5000/alpine: unable to pull image: Source image rejected: Invalid GPG signature: …
```

4
docs/tutorials/mac_win_client.md
View File

@ -36,7 +36,7 @@ $ systemctl --user enable --now podman.socket
You will need to enable linger for this user in order for the socket to work when the user is not logged in.
```
$ sudo loginctl enable-linger $USER
sudo loginctl enable-linger $USER
```
You can verify that the socket is listening with a simple Podman command.
@ -55,7 +55,7 @@ host:
In order for the client to communicate with the server you need to enable and start the SSH daemon on your Linux machine, if it is not currently enabled.
```
$ sudo systemctl enable -s sshd
sudo systemctl enable --now -s sshd
```
#### Setting up SSH

14
docs/tutorials/podman_tutorial.md
View File

@ -41,7 +41,7 @@ Note: If you add *-a* to the *ps* command, Podman will show all containers.
You can "inspect" a running container for metadata and details about itself. We can even use
the inspect subcommand to see what IP address was assigned to the container. As the container is running in rootless mode, an IP address is not assigned and the value will be listed as "none" in the output from inspect.
```console
$ podman inspect -l | grep IPAddress\":
podman inspect -l | grep IPAddress\":
"SecondaryIPAddresses": null,
"IPAddress": "",
```
@ -60,7 +60,7 @@ curl http://<IP_address>:8080
### Viewing the container's logs
You can view the container's logs with Podman as well:
```console
$ sudo podman logs --latest
podman logs --latest
10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-"
10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-"
10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-"
@ -71,7 +71,7 @@ $ sudo podman logs --latest
### Viewing the container's pids
And you can observe the httpd pid in the container with *top*.
```console
$ sudo podman top <container_id>
podman top <container_id>
UID PID PPID C STIME TTY TIME CMD
0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off;
101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process
@ -81,6 +81,8 @@ $ sudo podman top <container_id>
Checkpointing a container stops the container while writing the state of all processes in the container to disk.
With this a container can later be restored and continue running at exactly the same point in time as the
checkpoint. This capability requires CRIU 3.11 or later installed on the system.
This feature is not supported as rootless; as such, if you wish to try it, you'll need to re-create your container as root, using the same command but with sudo.
To checkpoint the container use:
```console
sudo podman container checkpoint <container_id>
@ -124,18 +126,18 @@ curl http://<IP_address>:8080
### Stopping the container
To stop the httpd container:
```console
sudo podman stop --latest
podman stop --latest
```
You can also check the status of one or more containers using the *ps* subcommand. In this case, we should
use the *-a* argument to list all containers.
```console
sudo podman ps -a
podman ps -a
```
### Removing the container
To remove the httpd container:
```console
sudo podman rm --latest
podman rm --latest
```
You can verify the deletion of the container by running *podman ps -a*.

18
docs/tutorials/remote_client.md
View File

@ -29,19 +29,19 @@ You will need to [install Podman](https://podman.io/getting-started/installation
Before performing any Podman client commands, you must enable the podman.sock SystemD service on the Linux server. In these examples, we are running Podman as a normal, unprivileged user, also known as a rootless user. By default, the rootless socket listens at `/run/user/${UID}/podman/podman.sock`. You can enable this socket permanently using the following command:
```
$ systemctl --user enable podman.socket
systemctl --user enable --now podman.socket
```
You will need to enable linger for this user in order for the socket to work when the user is not logged in:
```
$ sudo loginctl enable-linger $USER
sudo loginctl enable-linger $USER
```
This is only required if you are not running Podman as root.
You can verify that the socket is listening with a simple Podman command.
```
$ podman --remote info
podman --remote info
host:
arch: amd64
buildahVersion: 1.16.0-dev
@ -54,13 +54,13 @@ host:
In order for the Podman client to communicate with the server you need to enable and start the SSH daemon on your Linux machine, if it is not currently enabled.
```
$ sudo systemctl enable -s sshd
sudo systemctl enable --now -s sshd
```
#### Setting up SSH
Remote Podman uses SSH to communicate between the client and server. The remote client works considerably smoother using SSH keys. To set up your ssh connection, you need to generate an ssh key pair from your client machine.
```
$ ssh-keygen
ssh-keygen
```
Your public key by default should be in your home directory under ~/.ssh/id_rsa.pub. You then need to copy the contents of id_rsa.pub and append it into ~/.ssh/authorized_keys on the Linux server. You can automate this using ssh-copy-id.
@ -75,13 +75,13 @@ The first step in using the Podman remote client is to configure a connection.
You can add a connection by using the `podman-remote system connection add` command.
```
$ podman-remote system connection add myuser --identity ~/.ssh/id_rsa ssh://192.168.122.1/run/user/1000/podman/podman.sock
podman-remote system connection add myuser --identity ~/.ssh/id_rsa ssh://192.168.122.1/run/user/1000/podman/podman.sock
```
This will add a remote connection to Podman and if it is the first connection added, it will mark the connection as the default. You can observe your connections with `podman-remote system connection list`:
```
$ podman-remote system connection list
podman-remote system connection list
Name Identity URI
myuser* id_rsa ssh://myuser@192.168.122.1/run/user/1000/podman/podman.sock
```
@ -89,7 +89,7 @@ myuser* id_rsa ssh://myuser@192.168.122.1/run/user/1000/podman/podman.s
Now we can test the connection with `podman info`:
```
$ podman-remote info
podman-remote info
host:
arch: amd64
buildahVersion: 1.16.0-dev
@ -101,7 +101,7 @@ host:
Podman-remote has also introduced a “--connection” flag where you can use other connections you have defined. If no connection is provided, the default connection will be used.
```
$ podman-remote system connection --help
podman-remote system connection --help
```
## Wrap up

8
docs/tutorials/rootless_tutorial.md
View File

@ -6,14 +6,14 @@ Prior to allowing users without root privileges to run Podman, the administrator
## cgroup V2 support
The cgroup V2 Linux kernel feature allows the user to limit the amount of resources a rootless container can use. If the Linux distribution that you are running Podman on is enabled with cgroup V2 then you might need to change the default OCI Runtime. The default runtime `runc` does not currently work with cgroup V2 enabled systems, so you have to switch to the alternative OCI runtime `crun`.
The cgroup V2 Linux kernel feature allows the user to limit the amount of resources a rootless container can use. If the Linux distribution that you are running Podman on is enabled with cgroup V2 then you might need to change the default OCI Runtime. Some older versions of `runc` do not work with cgroup V2, you might have to switch to the alternative OCI runtime `crun`.
The alternative OCI runtime support for cgroup V2 can be turned on at the command line by using the `--runtime` option:
The alternative OCI runtime support for cgroup V2 can also be turned on at the command line by using the `--runtime` option:
```
sudo podman --runtime /usr/bin/crun
podman --runtime crun
```
or by changing the value for the "Default OCI runtime" in the containers.conf file either at the system level or at the [user level](#user-configuration-files) from `runtime = "runc"` to `runtime = "crun"`.
or for all commands by changing the value for the "Default OCI runtime" in the containers.conf file either at the system level or at the [user level](#user-configuration-files) from `runtime = "runc"` to `runtime = "crun"`.
## Administrator Actions