Docker & Kubernetes knowledge repo - q-uest/notes-doc-k8s-docker-jenkins-all-else GitHub Wiki

++docker++start a container as root user++change default user of an image++run container as a non-default user++

specify the user to be connected as, "--user" option as below with the "docker exec" command:

docker run --name postgresql -d -e POSTGRESQL_USERNAME=my_user -e POSTGRESQL_PASSWORD=password123 -e POSTGRESQL_DATABASE=my_database bitnami/postgresql:11.7.0-debian-10-r26

docker exec --user 0 -it postgresql  /bin/bash

The above one starts the container as "root" user, instead of the default user, "postgres".

======

++override entrypoint command++change entrypoint command given with a different one in a container/image++

use "--entrypoint" with the run command and provide the command that you wanted to override the default one with the image.

docker run --name postgresql -it --entrypoint /bin/bash -e POSTGRESQL_USERNAME=my_user -e POSTGRESQL_PASSWORD=password123 -e POSTGRESQL_DATABASE=my_database  postgres-chk

======

How do you execute Docker commands - RUN,CMD,ENTRYPOINT in different ways/forms?

1. Shell form

2. Exec form

3. Commands are written without [] brackets and are run by the container's shell, such as /bin/sh -c. Example:

Example:

FROM alpine:latest

# /bin/sh -c 'echo $HOME'
RUN echo $HOME

# /bin/sh -c 'echo $PATH'
CMD echo $PATH

2. This is run directly, not through a shell:

Example:

FROM alpine:latest

RUN ["pwd"]

CMD ["sleep", "1s"]

===

** Which form (shell or exec form) is recommended to use for executing commands - RUN, CMD, ENTRYPOINT ?**

• Most Dockerfiles are written with the shell form for RUN for the niceties as well as layer reduction. Suits to use with "RUN".

• Most shells do not forward process signals to child processes, which means the SIGINT generated by pressing CTRL-C may not stop a child process. Suits for "CMD" & "ENTRYPOINT".

• In general, use the shell form for RUN, and the exec form for everything else.

Reference:

https://emmer.dev/blog/docker-shell-vs.-exec-form/

=====

++k8's security context ++ security context ++ pod's security context ++

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000  
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

In the configuration file, the runAsUser field specifies that for any Containers in the Pod, all processes run with user ID 1000. The runAsGroup field specifies the primary group ID of 3000 for all processes within any containers of the Pod. If this field is omitted, the primary group ID of the containers will be root(0). Any files created will also be owned by user 1000 and group 3000 when runAsGroup is specified. Since fsGroup field is specified, all processes of the container are also part of the supplementary group ID 2000. The owner for volume /data/demo and any files created in that volume will be Group ID 2000.

====

how do you setup a Pod's owner/group to be a specific entity (for e.g. both owner/group to be ubuntu) and secondary group as root?

Set it at the Pod level as below:

    spec:
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 0

The userid/groupid of ubuntu is 1000.

=====

++kubernetes node issues++node notready++k8s node notready+node issue++node not ready ++ https://komodor.com/learn/how-to-fix-kubernetes-node-not-ready-error/