containers
/
podman
mirror of https://github.com/containers/podman.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Cleanup tutorials 

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
No known key found for this signature in database
GPG Key ID: A2DF901DABE2C028
5 changed files with 36 additions and 34 deletions
Show Stats 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: start one on our local machine:
```bash ```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 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: Let’s choose a standard `alpine` image for our signing experiment:
```bash ```bash
> sudo podman pull docker://docker.io/alpine:latest sudo podman pull docker://docker.io/alpine:latest
``` ```
```bash ```bash
> sudo podman images alpine sudo podman images alpine
REPOSITORY TAG IMAGE ID CREATED SIZE REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/library/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB 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: Now we can re-tag the image to point it to our local registry:
```bash ```bash
> sudo podman tag alpine localhost:5000/alpine sudo podman tag alpine localhost:5000/alpine
``` ```
```bash ```bash
> sudo podman images alpine sudo podman images alpine
REPOSITORY TAG IMAGE ID CREATED SIZE REPOSITORY TAG IMAGE ID CREATED SIZE
localhost:5000/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB localhost:5000/alpine latest e7d92cdc71fe 6 weeks ago 5.86 MB
docker.io/library/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: Now, let’s push and sign the image:
```bash ```bash
> sudo -E GNUPGHOME=$HOME/.gnupg \ sudo -E GNUPGHOME=$HOME/.gnupg \
podman push \ podman push \
--tls-verify=false \ --tls-verify=false \
--sign-by sgrunert@suse.com \ --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: is a new signature available, which was caused by the image push:
```bash ```bash
> sudo ls /var/lib/containers/sigstore sudo ls /var/lib/containers/sigstore
'alpine@sha256=e9b65ef660a3ff91d28cc50eba84f21798a6c5c39b4dd165047db49e84ae1fb9' 'alpine@sha256=e9b65ef660a3ff91d28cc50eba84f21798a6c5c39b4dd165047db49e84ae1fb9'
``` ```
@ -107,14 +107,14 @@ The default signature store in our edited version of
the local staging signature store: the local staging signature store:
```bash ```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/) ... 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: 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 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: The `keyPath` does not exist yet, so we have to put the GPG key there:
```bash ```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: If we now pull the image:
```bash ```bash
> sudo podman pull --tls-verify=false localhost:5000/alpine sudo podman pull --tls-verify=false localhost:5000/alpine
… …
Storing signatures Storing signatures
e7d92cdc71feacf90708cb59182d0df1b911f8ae022d29e8e95d75ca6a99776a e7d92cdc71feacf90708cb59182d0df1b911f8ae022d29e8e95d75ca6a99776a
@ -164,14 +164,14 @@ accessed:
As an counterpart example, if we specify the wrong key at `/tmp/key.gpg`: As an counterpart example, if we specify the wrong key at `/tmp/key.gpg`:
```bash ```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 File '/tmp/key.gpg' exists. Overwrite? (y/N) y
``` ```
Then a pull is not possible any more: Then a pull is not possible any more:
```bash ```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... 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: … 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. 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. 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. 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 #### 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 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. 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 ```console
$ podman inspect -l | grep IPAddress\": podman inspect -l | grep IPAddress\":
"SecondaryIPAddresses": null, "SecondaryIPAddresses": null,
"IPAddress": "", "IPAddress": "",
``` ```
@ -60,7 +60,7 @@ curl http://<IP_address>:8080
### Viewing the container's logs ### Viewing the container's logs
You can view the container's logs with Podman as well: You can view the container's logs with Podman as well:
```console ```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: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" "-"
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 ### Viewing the container's pids
And you can observe the httpd pid in the container with *top*. And you can observe the httpd pid in the container with *top*.
```console ```console
$ sudo podman top <container_id> podman top <container_id>
UID PID PPID C STIME TTY TIME CMD UID PID PPID C STIME TTY TIME CMD
0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off; 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 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. 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 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. 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: To checkpoint the container use:
```console ```console
sudo podman container checkpoint <container_id> sudo podman container checkpoint <container_id>
@ -124,18 +126,18 @@ curl http://<IP_address>:8080
### Stopping the container ### Stopping the container
To stop the httpd container: To stop the httpd container:
```console ```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 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. use the *-a* argument to list all containers.
```console ```console
sudo podman ps -a podman ps -a
``` ```
### Removing the container ### Removing the container
To remove the httpd container: To remove the httpd container:
```console ```console
sudo podman rm --latest podman rm --latest
``` ```
You can verify the deletion of the container by running *podman ps -a*. 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: 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: 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. 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. You can verify that the socket is listening with a simple Podman command.
``` ```
$ podman --remote info podman --remote info
host: host:
arch: amd64 arch: amd64
buildahVersion: 1.16.0-dev 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. 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 #### 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. 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. 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. 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`: 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 Name Identity URI
myuser* id_rsa ssh://myuser@192.168.122.1/run/user/1000/podman/podman.sock 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`: Now we can test the connection with `podman info`:
``` ```
$ podman-remote info podman-remote info
host: host:
arch: amd64 arch: amd64
buildahVersion: 1.16.0-dev 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 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 ## 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 ## 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 ## Administrator Actions