Fichier Docker
1 fichier Docker
Processus de construction
dockerfile est utilisé pour créer des fichiers image Docker ! script de paramètre de commande
Étapes de construction
- fichier docker
- docker build crée une image
- Docker Run exécute l'image
- docker push publie une image
L'image officielle du dockerhub correspondra au Dockerfile dans un entrepôt sur github.
instruction
FROM 基础镜像
MAINTAINER 镜像的维护者信息
RUN Docker镜像构建的时候需要的命令
ADD 步骤：tomcat的镜像中，tomcat的压缩包
WORKDIR 镜像的工作目录
VOLUME -v挂载的目录位置
EXPOSE -p暴露端口
CMD 指定这个容器启动的时候运行的命令，只有最后一个会生效，而且可悲替代
ENTRYPOINT 指定这个容器启动的时候运行的命令，可以追加命令
ONBUILD 当构建一个被继承的DockerfileFile，就会影响ONBUILD指令。触发指令
COPY 类似ADD命令，将文件COPY到镜像中。
ENV 构建的时候设置环境变量
- Chaque directive de mot-clé réservé est en majuscule
#Indique des commentaires- Chaque commande créera et soumettra un nouveau calque d'image et le soumettra
Le rôle de DockFile
Dockerfile est orienté développement. Pour publier un projet et créer un miroir, vous devez écrire un dockerfile.
- DockerFile : fichier de construction, qui définit toutes les étapes et le code source
- DockerImages : l'image générée par la construction de DockerFile, le produit final publié et en cours d'exécution
- Conteneur Docker : un conteneur est une image qui s'exécute et fournit un serveur
Pratique : Créez vos propres centos
99 % des images du Docker Hub proviennent de zéro
- Écrivez le fichier dockerfile
➜ dockerfile git:(master) ✗ cat mydockerfile
FROM centos
MAINTAINER yinkanglong<yinkanglong.163.com>
ENV MYPATH /usr/local
WORKDIR $MYPATH
RUN yum -y install vim
RUN yum -y install net-tools
EXPOSE 80
CMD echo $MYPATH
CMD echo "----end----"
CMD /bin/bash
- image d'exécution créée par Docker
dockerfile git:(master) ✗ docker build -f mydockerfile -t mycentos:0.1 .
[+] Building 64.0s (8/8) FINISHED
=> [internal] load build definition from mydockerfile 0.2s
=> => transferring dockerfile: 265B 0.1s
=> [internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/centos:7 4.5s
=> [1/4] FROM docker.io/library/centos:7@sha256:c73f515d06b0fa07bb18d8202035e739a494ce760aa73129f60f4bf2bd22b407 20.6s
=> => resolve docker.io/library/centos:7@sha256:c73f515d06b0fa07bb18d8202035e739a494ce760aa73129f60f4bf2bd22b407 0.0s
=> => sha256:c73f515d06b0fa07bb18d8202035e739a494ce760aa73129f60f4bf2bd22b407 1.20kB / 1.20kB 0.0s
=> => sha256:dead07b4d8ed7e29e98de0f4504d87e8880d4347859d839686a31da35a3b532f 529B / 529B 0.0s
=> => sha256:eeb6ee3f44bd0b5103bb561b4c16bcb82328cfe5809ab675bb17ab3a16c517c9 2.75kB / 2.75kB 0.0s
=> => sha256:2d473b07cdd5f0912cd6f1a703352c82b512407db6b05b43f2553732b55df3bc 76.10MB / 76.10MB 15.0s
=> => extracting sha256:2d473b07cdd5f0912cd6f1a703352c82b512407db6b05b43f2553732b55df3bc 5.3s
=> [2/4] WORKDIR /usr/local 0.6s
=> [3/4] RUN yum -y install vim 21.9s
=> [4/4] RUN yum -y install net-tools 9.3s
=> exporting to image 6.1s
=> => exporting layers 6.1s
=> => writing image sha256:87b7be8e41c9cc237c733930df0513f40a708fb0944f5ef48e815979e6880ee2 0.0s
=> => naming to docker.io/library/mycentos:0.1 0.0s
Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
- Testez l'exécution de Docker Run pour vérifier que les commandes vim et ifconfig sont réalisables
dockerfile git:(master) ✗ docker run -it mycentos:0.1
[root@f318e4ba01b3 local]# pwd
/usr/local
[root@f318e4ba01b3 local]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.2 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:ac:11:00:02 txqueuelen 0 (Ethernet)
RX packets 10 bytes 876 (876.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@f318e4ba01b3 local]# vim where
[root@f318e4ba01b3 local]# which vim
/usr/bin/vim
Pratique : CMD et ENTRYPOINT
- Écrire un fichier dockerfile
vim dockerfile-cmd-test
FROM centos
CMD ["ls","-a"]
- Construire une image
docker build -f dockerfile-cmd-test -t cmdtest
- Exécuter l'image
docker run cmdtest
- image de test
发现CMD追加命令报错，发现ENTRYPOINT命令追加的命令是可以执行的。
docker run cmtest -l
Pratique : Créer une image de chat
Plus complexe, sera ajouté plus tard
2 Publiez votre propre image
Publiez votre propre image sur Dockerhub
DockeHub
- Créez un compte sur https://hub.docker.com
- Soumettez votre propre image au serveur
- 登录 docker login -u yinkanglong
- Pousser docker pousser yinkanglong/mycentos:01
Publiez votre propre image sur Alibaba Cloud
- Connectez-vous à Alibaba Cloud
- Demander l'adresse de l'entrepôt
- Connectez-vous à l'entrepôt Alibaba Cloud
- poussée du docker
Publier la sauvegarde du docker et le chargement du docker localement
-
Enregistrez l'image dans un package compressé
-
Charger le package compressé en tant qu'image
Résumer
3 Commande DockerFichier
Chaque instruction du Dockerfile crée une couche.
Construire une image
$ docker build -t nginx:v3 .
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM nginx
---> e43d811ce2f4
Step 2 : RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
---> Running in 9cdc27646c7b
---> 44aa4490ce2c
Removing intermediate container 9cdc27646c7b
Successfully built 44aa4490ce2c
- Créez directement avec le dépôt Git. La version Docker prend également en charge la création à partir d'une URL. Par exemple, vous pouvez créer directement à partir du dépôt Git :
$ docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14
docker build https://github.com/twang2218/gitlab-ce-zh.git\#:8.14
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM gitlab/gitlab-ce:8.14.0-ce.0
8.14.0-ce.0: Pulling from gitlab/gitlab-ce
aed15891ba52: Already exists
773ae8583d14: Already exists
...
- Construire avec l'archive tar donnée
$ docker build http://server/context.tar.gz
- Lire le Dockerfile à partir de l'entrée standard pour construire
docker build - < Dockerfile
或
cat Dockerfile | docker build -
- Lire l'archive contextuelle à partir de l'entrée standard pour construire
$ docker build - < context.tar.gz
Contexte de création d'image (Contexte)
La commande docker build a un... à la fin. . représente le répertoire courant et le Dockerfile est dans le répertoire courant, donc de nombreux débutants pensent que ce chemin spécifie le chemin où se trouve le Dockerfile. Cette compréhension est en fait inexacte. Si vous correspondez au format de commande ci-dessus, vous constaterez peut-être qu'il s'agit de spécifier le chemin du contexte.
Nous devons d’abord comprendre comment fonctionne la construction de Docker. Docker est divisé en moteur Docker (c'est-à-dire démon côté serveur) et outils côté client au moment de l'exécution. Le moteur Docker fournit un ensemble d'API REST, appelé Docker Remote API, et des outils clients tels que les commandes Docker interagissent avec le moteur Docker via cet ensemble d'API pour remplir diverses fonctions.
Lorsque nous construisons une image, toutes les personnalisations ne seront pas effectuées via la commande RUN. Nous devons souvent copier certains fichiers locaux dans l'image, par exemple via la commande COPY, la commande ADD, etc. La commande docker build pour créer l'image n'est pas réellement construite localement, mais sur le serveur, c'est-à-dire dans le moteur Docker. Alors dans cette architecture client/serveur, comment le serveur peut-il obtenir des fichiers locaux ?
Cela introduit la notion de contexte. Lors de la construction, l'utilisateur spécifiera le chemin pour créer le contexte de l'image. Une fois que la commande docker build aura appris ce chemin, elle regroupera tout le contenu sous le chemin, puis le téléchargera sur le moteur Docker. De cette façon, une fois que le moteur Docker aura reçu le package de contexte, il se développera et obtiendra tous les fichiers nécessaires à la création de l'image.
DEPUIS
Spécifiez une image de base
. L'image dite personnalisée doit être basée sur une image et personnalisée par-dessus celle-ci. Tout comme nous avons précédemment exécuté un conteneur avec une image nginx puis l'avons modifié, l'image de base doit être spécifiée. FROM spécifie l'image de base, donc FROM est une instruction nécessaire dans un Dockerfile et doit être la première instruction.
Il existe de nombreuses images officielles de haute qualité sur Docker Hub (https://hub.docker.com/explore/), ainsi que des images de type service qui peuvent être utilisées directement, telles que nginx, redis, mongo, mysql, httpd. , php, tomcat, etc.
En plus de sélectionner une image existante comme image de base, Docker dispose également d'une image spéciale appelée scratch. Cette image est un concept virtuel et n’existe pas réellement, elle représente une image vierge.
Pour les programmes compilés statiquement sous Linux, il n'est pas nécessaire qu'un système d'exploitation fournisse un support d'exécution. Toutes les bibliothèques requises sont déjà dans le fichier exécutable, donc directement à partir de zéro réduira la taille de l'image. De nombreuses applications développées à l'aide du langage Go utilisent cette méthode pour créer des images, ce qui est une des raisons pour lesquelles certains pensent que Go est un langage particulièrement adapté à l'architecture de microservices de conteneurs.
FROM scratch
...
Commande d'exécution RUN
L'instruction RUN est utilisée pour exécuter des commandes de ligne de commande. En raison des puissantes capacités de la ligne de commande, la commande RUN est l'une des commandes les plus couramment utilisées lors de la personnalisation des images. Il existe deux formats :
- Format du shell : RUN <command>, tout comme une commande saisie directement sur la ligne de commande. L'instruction RUN dans le Dockrfile qui vient d'être écrit est dans ce format.
- format exec : RUN ["fichier exécutable", "paramètre 1", "paramètre 2"], cela ressemble plus au format des appels de fonction.
RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
Comme un script shell, mappez chaque commande à un RUN
FROM debian:jessie
RUN apt-get update
RUN apt-get install -y gcc libc6-dev make
RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz"
RUN mkdir -p /usr/src/redis
RUN tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1
RUN make -C /usr/src/redis
RUN make -C /usr/src/redis install
La méthode d'écriture ci-dessus crée une image à 7 couches. Cela n'a aucun sens et de nombreux éléments qui ne sont pas nécessaires à l'exécution sont installés dans l'image, tels que l'environnement de compilation, les progiciels mis à jour, etc. Le résultat est une image multicouche très volumineuse, qui non seulement augmente le temps de création et de déploiement, mais est également sujette aux erreurs.
Manière correcte d'écrire Dockerfile
FROM debian:jessie
RUN buildDeps='gcc libc6-dev make' \
&& apt-get update \
&& apt-get install -y $buildDeps \
&& wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz" \
&& mkdir -p /usr/src/redis \
&& tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 \
&& make -C /usr/src/redis \
&& make -C /usr/src/redis install \
&& rm -rf /var/lib/apt/lists/* \
&& rm redis.tar.gz \
&& rm -r /usr/src/redis \
&& apt-get purge -y --auto-remove $buildDeps
Des sauts de ligne sont également effectués ici à des fins de formatage. Dockerfile prend en charge la méthode d'encapsulage de ligne de commande consistant à ajouter \ à la fin de la ligne de la classe Shell et le format de commentaire # au début de la ligne. Un bon formatage, tel que les sauts de ligne, l'indentation, les commentaires, etc., facilitera la maintenance et le dépannage, ce qui est une bonne habitude.
De plus, vous pouvez également voir qu'une commande de nettoyage est ajoutée à la fin de cet ensemble de commandes, qui supprime le logiciel requis pour la compilation et la construction, nettoie tous les fichiers téléchargés et développés, et nettoie également le fichier de cache apt. C'est une étape très importante. Comme nous l'avons dit précédemment, la mise en miroir est un stockage multicouche. Les éléments de chaque couche ne seront pas supprimés sur la couche suivante, mais suivront toujours le miroir. Par conséquent, lors de la création d’une image, vous devez vous assurer que seul ce qui est réellement nécessaire est ajouté à chaque calque et que tout élément non pertinent doit être nettoyé.
COPIER Copier les fichiers
L'instruction COPY copiera les fichiers/répertoires à <chemin source> dans le répertoire de contexte de construction vers l'emplacement <chemin cible> dans la nouvelle couche de l'image.
COPY package.json /usr/src/app/
AJOUTER une copie de fichier avancée
Le format et les propriétés des instructions ADD et COPY sont fondamentalement les mêmes. Mais certaines fonctions sont ajoutées en fonction de COPY.
- Si <chemin source> peut être une URL, dans ce cas, le moteur Docker tentera de télécharger le fichier lié et de le placer dans <chemin cible>. Les autorisations de fichiers après le téléchargement sont automatiquement définies sur 600
- Si <chemin source> est un fichier compressé tar et que le format de compression est gzip, bzip2 et xz, la commande ADD décompressera automatiquement le fichier compressé en <chemin de destination>.
FROM scratch
ADD ubuntu-xenial-core-cloudimg-amd64-root.tar.gz /
...
Commande de démarrage du conteneur CMD
L'instruction CMD est utilisée pour spécifier la commande de démarrage par défaut du processus principal du conteneur.
Le format de l'instruction CMD est similaire à celui de RUN, et il existe deux formats :
- format du shell : CMD <commande>
- format d'exécution : CMD ["fichier exécutable", "paramètre 1", "paramètre 2"...]
- Format de la liste des paramètres : CMD ["Paramètre 1", "Paramètre 2"...]. Après avoir spécifié la commande ENTRYPOINT, utilisez CMD pour spécifier des paramètres spécifiques.
Lors de l'exécution, vous pouvez spécifier une nouvelle commande pour remplacer la commande par défaut dans les paramètres de l'image. Par exemple, le CMD par défaut de l'image Ubuntu est /bin/bash. Si nous exécutons directement -it ubuntu par docker, nous entrerons directement bash. Nous pouvons également spécifier d'autres commandes à exécuter au moment de l'exécution, telles que docker run -it ubuntu cat /etc/os-release. Cela signifie remplacer la commande par défaut /bin/bash par la commande cat /etc/os-release et afficher les informations de version du système.
POINT D'ACCÈS
Le format d'ENTRYPOINT est le même que le format de l'instruction RUN et est divisé en format exec et format shell.
L'objectif d'ENTRYPOINT est le même que celui de CMD, qui consiste à spécifier le programme et les paramètres de démarrage du conteneur. ENTRYPOINT peut également être remplacé au moment de l'exécution, mais il est légèrement plus lourd que CMD et doit être spécifié via le paramètre --entrypoint de docker run.
- La commande CMD ne peut pas ajouter de paramètres, mais la commande ENTRYPOINT peut ajouter des paramètres.
FROM ubuntu:16.04
RUN apt-get update \
&& apt-get install -y curl \
&& rm -rf /var/lib/apt/lists/*
ENTRYPOINT [ "curl", "-s", "http://ip.cn" ]
$ docker run myip
当前 IP：61.148.226.66 来自：北京市 联通
$ docker run myip -i
HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Tue, 22 Nov 2016 05:12:40 GMT
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
X-Powered-By: PHP/5.6.24-1~dotdeb+7.1
X-Cache: MISS from cache-2
X-Cache-Lookup: MISS from cache-2:80
X-Cache: MISS from proxy-2_6
Transfer-Encoding: chunked
Via: 1.1 cache-2:80, 1.1 proxy-2_6:8006
Connection: keep-alive
当前 IP：61.148.226.66 来自：北京市 联通
- ENTRYPOINT et CMD sont combinés pour ajouter des paramètres supplémentaires. Vous pouvez écrire un script puis le placer dans ENTRYPOINT pour exécution, et ce script utilisera les paramètres reçus (c'est-à-dire) comme commande et l'exécutera à la fin du script.
FROM alpine:3.4
...
RUN addgroup -S redis && adduser -S -G redis redis
...
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 6379
CMD [ "redis-server" ]
ENV définit les variables d'environnement
Il existe deux formats :
ENV <key> <value>
ENV <key1>=<value1> <key2>=<value2>...
Cette commande est très simple, elle définit simplement les variables d'environnement. Qu'il s'agisse d'autres commandes ultérieures, comme RUN, ou d'applications d'exécution, vous pouvez directement utiliser les variables d'environnement définies ici.
ENV VERSION=1.0 DEBUG=on \
NAME="Happy Feet"
ENV NODE_VERSION 7.2.0
RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.xz" \
&& curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \
&& gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \
&& grep " node-v$NODE_VERSION-linux-x64.tar.xz\$" SHASUMS256.txt | sha256sum -c - \
&& tar -xJf "node-v$NODE_VERSION-linux-x64.tar.xz" -C /usr/local --strip-components=1 \
&& rm "node-v$NODE_VERSION-linux-x64.tar.xz" SHASUMS256.txt.asc SHASUMS256.txt \
&& ln -s /usr/local/bin/node /usr/local/bin/nodejs
Paramètres de construction ARG
格式：ARG <参数名>[=<默认值>]
Les paramètres de construction ont le même effet que ENV, définissant les variables d'environnement. La différence est que les variables d'environnement de l'environnement de construction définies par ARG n'existeront pas lors de l'exécution future du conteneur. Mais n'utilisez pas ARG pour enregistrer des informations telles que des mots de passe, car l'historique du Docker peut toujours voir toutes les valeurs.
La directive ARG du Dockerfile définit les noms des paramètres et définit leurs valeurs par défaut. Cette valeur par défaut peut être remplacée par --build-arg <argument name>=<value> dans la commande build docker build.
VOLUME définit un volume anonyme
Le format est :
VOLUME ["<路径1>", "<路径2>"...]
VOLUME <路径>
Nous avons déjà dit que lorsque le conteneur est en cours d'exécution, nous devrions essayer d'empêcher la couche de stockage du conteneur d'écrire des opérations. Pour les applications de base de données qui ont besoin de sauvegarder des données dynamiques, leurs fichiers de base de données doivent être stockés dans des volumes. Nous présenterons plus en détail les volumes Docker dans les chapitres suivants.le concept de. Afin d'éviter que les utilisateurs n'oublient de monter le répertoire dans lequel les fichiers dynamiques sont enregistrés en tant que volumes pendant l'exécution, dans le Dockerfile, nous pouvons spécifier à l'avance certains répertoires à monter en tant que volumes anonymes, de sorte que si l'utilisateur ne spécifie pas le montage au moment de l'exécution , l'application peut fonctionner normalement et s'exécuter sans écrire de grandes quantités de données sur la couche de stockage du conteneur.
VOLUME /data
Le répertoire /data ici sera automatiquement monté en tant que volume anonyme au moment de l'exécution, et toute information écrite dans /data ne sera pas enregistrée dans la couche de stockage du conteneur, garantissant ainsi l'apatridie de la couche de stockage du conteneur. Bien entendu, ce paramètre de montage peut être remplacé au moment de l'exécution. Par exemple:
docker run -d -v mydata:/data xxxx
Dans cette ligne de commande, le volume nommé mydata est utilisé pour le monter à l'emplacement /data, remplaçant la configuration de montage du volume anonyme défini dans le Dockerfile.
EXPOSE exposer le port
格式为 EXPOSE <端口1> [<端口2>...]。
La directive EXPOSE déclare que le conteneur d'exécution fournit un port de service. Il s'agit simplement d'une instruction. L'application n'ouvrira pas le service de ce port au moment de l'exécution à cause de cette instruction. L'écriture d'une telle instruction dans le Dockerfile présente deux avantages. L'un est d'aider les utilisateurs d'images à comprendre le port de garde du service d'imagerie pour faciliter le mappage de configuration ; l'autre est d'utiliser un mappage de port aléatoire au moment de l'exécution, c'est-à-dire docker run -P, le Le port EXPOSE sera automatiquement et aléatoirement mappé.
WORKDIR spécifie le répertoire de travail
格式为 WORKDIR <工作目录路径>。
Vous pouvez utiliser la commande WORKDIR pour spécifier le répertoire de travail (ou répertoire actuel). À l'avenir, le répertoire actuel de chaque couche sera remplacé par le répertoire spécifié. Si le répertoire n'existe pas, WORKDIR vous aidera à créer le répertoire.
Comme mentionné précédemment, une erreur courante commise par certains débutants est d'écrire Dockerfile en tant que script Shell. Cette mauvaise compréhension peut également conduire aux erreurs suivantes :
RUN cd /app
RUN echo "hello" > world.txt
Si vous exécutez ce Dockerfile pour créer l'image, vous constaterez que le fichier /app/world.txt est introuvable ou que son contenu n'est pas bonjour. La raison est en réalité très simple : dans le Shell, deux lignes consécutives représentent le même environnement d'exécution du processus, donc l'état mémoire modifié par la commande précédente affectera directement la commande suivante ; dans le Dockerfile, les environnements d'exécution des deux lignes de RUN les commandes sont fondamentalement différentes. , sont deux conteneurs complètement différents. Il s'agit d'une erreur causée par une non-compréhension du concept de création de stockage hiérarchique dans Dokerfile.
USER spécifie l'utilisateur actuel
格式：USER <用户名>
La commande USER est similaire à WORKDIR dans la mesure où elle modifie l'état de l'environnement et affecte les couches suivantes. WORKDIR consiste à changer le répertoire de travail, USER doit modifier l'identité de la couche suivante pour exécuter des commandes telles que RUN, CMD et ENTRYPOINT.
Bien entendu, comme WORKDIR, USER vous aide uniquement à basculer vers l'utilisateur spécifié. Cet utilisateur doit être créé à l'avance, sinon vous ne pouvez pas basculer.
RUN groupadd -r redis && useradd -r -g redis redis
USER redis
RUN [ "redis-server" ]
Si vous souhaitez modifier l'identité d'un script exécuté en tant que root pendant l'exécution, par exemple si vous souhaitez exécuter un processus de service en tant qu'utilisateur déjà établi, n'utilisez pas su ou sudo. Ceux-ci nécessitent une configuration plus compliquée et le TTY est L’environnement se détériore souvent. Il est recommandé d'utiliser gosu, de plus amples informations peuvent être consultées sur le site Web de son projet : https://github.com/tianon/gosu
# 建立 redis 用户，并使用 gosu 换另一个用户执行命令
RUN groupadd -r redis && useradd -r -g redis redis
# 下载 gosu
RUN wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/1.7/gosu-amd64" \
&& chmod +x /usr/local/bin/gosu \
&& gosu nobody true
# 设置 CMD，并以另外的用户执行
CMD [ "exec", "gosu", "redis", "redis-server" ]