Pendant cette période, j'ai développé un service HTML dynamique commun à toutes les catégories de Documents Tencent afin de faciliter la génération et le déploiement des accès aux différentes catégories, et en conformité avec la tendance du passage au. cloud, j'envisage d'utiliser Docker pour corriger le contenu du service et le gérer de manière uniforme. Cet article partagera l'expérience d'optimisation que j'ai accumulée en train de servir Docker pour votre référence. [Recommandations de didacticiel associées?: Tutoriel vidéo Nodejs]

Commencez par un exemple. La plupart des étudiants qui découvrent Docker devraient écrire le fichier Docker du projet comme ceci, comme indiqué ci-dessous?:

FROM?node:14
WORKDIR?/app

COPY?.?.
#?安裝?npm?依賴
RUN?npm?install

#?暴露端口
EXPOSE?8000

CMD?["npm",?"start"]

Construire, empaqueter, télécharger, tout est inclus. un coup. Ensuite, regardez l'état de l'image, bon sang, le volume d'un simple service Web de n?ud a en fait atteint un étonnant 1,3 G, et la vitesse de transmission et de construction de l'image est également très lente :

Peu importe si cela. image n'a besoin de déployer qu'une seule instance. , mais ce service doit être fourni à tous les étudiants en développement pour les environnements d'intégration et de déploiement à haute fréquence (voir mon article précédent pour les solutions permettant de réaliser une intégration à haute fréquence). Tout d'abord, si la taille de l'image est trop grande, cela affectera inévitablement la vitesse d'extraction et de mise à jour de l'image, et l'expérience d'intégration sera pire. Deuxièmement, après le lancement du projet, des dizaines de milliers d'instances d'environnement de test peuvent être en ligne en même temps. Un tel co?t de consommation de mémoire de conteneur est inacceptable pour n'importe quel projet. Une solution optimisée doit être trouvée.

Après avoir découvert le problème, j'ai commencé à étudier le plan d'optimisation de Docker et je me suis préparé à opérer mon image.

Optimisation de l'environnement de production des projets de n?uds

La première chose à faire est bien s?r la zone la plus familière du front-end, en optimisant la taille du code lui-même. Typescript a été utilisé lors du développement du projet auparavant. Afin d'éviter des problèmes, le projet a été directement empaqueté à l'aide de tsc pour générer es5, puis exécuté directement. Il y a ici deux problèmes de volume principaux.Le premier est que le code source de l'environnement de développement n'a pas été traité et que le code js utilisé dans l'environnement de production n'a pas été compressé.

L'autre est que le node_modules référencé est trop volumineux. Comprend toujours de nombreux packages npm pour les environnements de développement et de débogage, tels que ts-node, typescript, etc. Maintenant qu'il est packagé dans js, ces dépendances devraient naturellement être supprimées.

De manière générale, puisque le code c?té serveur ne sera pas exposé comme le code front-end, les services exécutés sur des machines physiques sont plus soucieux de la stabilité et ne se soucient pas du volume supplémentaire, donc ces endroits ne sont généralement pas traités. Cependant, après la Dockerisation, à mesure que l'échelle de déploiement augmente, ces problèmes deviennent très évidents et doivent être optimisés dans l'environnement de production.

En fait, notre front-end conna?t très bien les méthodes d'optimisation de ces deux points. Si ce n'est pas l'objet de cet article, nous l'évoquerons brièvement. Pour le premier point, utilisez Webpack + babel pour rétrograder et compresser le code source Typescript. Si vous vous inquiétez du dépannage des erreurs, vous pouvez ajouter un sourcemap, mais c'est un peu redondant pour les images Docker, qui seront abordées plus tard. Pour le deuxième point, trier les dépendances et devDependencies du package npm, et supprimer les dépendances qui ne sont pas nécessaires à l'exécution pour faciliter l'utilisation dans l'environnement de production npm install --production Installer les dépendances.

Optimisez la taille de l'image du projet

Utilisez une image de base aussi simplifiée que possible

Nous savons que la technologie des conteneurs permet d'isoler les processus au niveau du système d'exploitation. Le conteneur Docker lui-même est un processus exécuté sous un système d'exploitation indépendant. , Docker L'image doit être regroupée dans un environnement au niveau du système d'exploitation qui peut s'exécuter indépendamment. Par conséquent, un facteur important dans la détermination de la taille de l’image devient évident : la taille du système d’exploitation Linux intégré à l’image.

D'une manière générale, pour réduire la taille du système d'exploitation dépendant, vous devez considérer deux aspects. Le premier est de supprimer autant de bibliothèques d'outils que possible qui ne sont pas nécessaires sous Linux, comme python, cmake, telnet, etc. La seconde consiste à choisir un système de distribution Linux plus léger. Les images officielles régulières devraient fournir des versions castrées de chaque version en fonction des deux facteurs ci-dessus.

Prenons comme exemple node:14, la version officiellement fournie de node. Dans la version par défaut, son environnement d'exécution de base est Ubuntu, qui est une distribution Linux vaste et complète pour garantir une compatibilité maximale. La version qui supprime les dépendances inutiles de la bibliothèque d’outils s’appelle la version node:14-slim. La plus petite distribution d’images s’appelle node:14-alpine. Linux alpine est une distribution Linux légère et très rationalisée qui ne contient que des outils de base. Sa propre image Docker ne mesure que 4 à 5 Mo, elle est donc très appropriée pour créer la plus petite version de l'image Docker.

Dans notre service, les dépendances pour faire fonctionner le service étant déterministes, afin de réduire au maximum la taille de l'image de base, nous choisissons la version alpine comme image de base pour l'environnement de production.

分級(jí)構(gòu)建

這時(shí)候，我們遇到了新的問題。由于 alpine 的基本工具庫過于簡(jiǎn)陋，而像 webpack 這樣的打包工具背后可能使用的插件庫極多，構(gòu)建項(xiàng)目時(shí)對(duì)環(huán)境的依賴較大。并且這些工具庫只有編譯時(shí)需要用到，在運(yùn)行時(shí)是可以去除的。對(duì)于這種情況，我們可以利用 Docker 的分級(jí)構(gòu)建的特性來解決這一問題。

首先，我們可以在完整版鏡像下進(jìn)行依賴安裝，并給該任務(wù)設(shè)立一個(gè)別名（此處為build)。

#?安裝完整依賴并構(gòu)建產(chǎn)物
FROM?node:14?AS?build
WORKDIR?/app

COPY?package*.json?/app/
RUN?["npm",?"install"]
COPY?.?/app/

RUN?npm?run?build

之后我們可以啟用另一個(gè)鏡像任務(wù)來運(yùn)行生產(chǎn)環(huán)境，生產(chǎn)的基礎(chǔ)鏡像就可以換成 alpine 版本了。其中編譯完成后的源碼可以通過--from參數(shù)獲取到處于build任務(wù)中的文件，移動(dòng)到此任務(wù)內(nèi)。

FROM?node:14-alpine?AS?release
WORKDIR?/release

COPY?package*.json?/
RUN?["npm",?"install",?"--registry=http://r.tnpm.oa.com",?"--production"]

#?移入依賴與源碼
COPY?public?/release/public
COPY?--from=build?/app/dist?/release/dist

#?啟動(dòng)服務(wù)
EXPOSE?8000

CMD?["node",?"./dist/index.js"]

Docker 鏡像的生成規(guī)則是，生成鏡像的結(jié)果僅以最后一個(gè)鏡像任務(wù)為準(zhǔn)。因此前面的任務(wù)并不會(huì)占用最終鏡像的體積，從而完美解決這一問題。

當(dāng)然，隨著項(xiàng)目越來越復(fù)雜，在運(yùn)行時(shí)仍可能會(huì)遇到工具庫報(bào)錯(cuò)，如果曝出問題的工具庫所需依賴不多，我們可以自行補(bǔ)充所需的依賴，這樣的鏡像體積仍然能保持較小的水平。

其中最常見的問題就是對(duì)node-gyp與node-sass庫的引用。由于這個(gè)庫是用來將其他語言編寫的模塊轉(zhuǎn)譯為 node 模塊，因此，我們需要手動(dòng)增加g++ make python這三個(gè)依賴。

#?安裝生產(chǎn)環(huán)境依賴（為兼容?node-gyp?所需環(huán)境需要對(duì)?alpine?進(jìn)行改造）
FROM?node:14-alpine?AS?dependencies

RUN?apk?add?--no-cache?python?make?g++
COPY?package*.json?/
RUN?["npm",?"install",?"--registry=http://r.tnpm.oa.com",?"--production"]
RUN?apk?del?.gyp

詳情可見：https://github.com/nodejs/docker-node/issues/282

合理規(guī)劃 Docker Layer

構(gòu)建速度優(yōu)化

我們知道，Docker 使用 Layer 概念來創(chuàng)建與組織鏡像，Dockerfile 的每條指令都會(huì)產(chǎn)生一個(gè)新的文件層，每層都包含執(zhí)行命令前后的狀態(tài)之間鏡像的文件系統(tǒng)更改，文件層越多，鏡像體積就越大。而 Docker 使用緩存方式實(shí)現(xiàn)了構(gòu)建速度的提升。若 Dockerfile 中某層的語句及依賴未更改，則該層重建時(shí)可以直接復(fù)用本地緩存。

如下所示，如果 log 中出現(xiàn)Using cache字樣時(shí)，說明緩存生效了，該層將不會(huì)執(zhí)行運(yùn)算，直接拿原緩存作為該層的輸出結(jié)果。

Step?2/3?:?npm?install
?--->?Using?cache
?--->?efvbf79sd1eb

通過研究 Docker 緩存算法，發(fā)現(xiàn)在 Docker 構(gòu)建過程中，如果某層無法應(yīng)用緩存，則依賴此步的后續(xù)層都不能從緩存加載。例如下面這個(gè)例子：

COPY?.?.
RUN?npm?install

此時(shí)如果我們更改了倉庫的任意一個(gè)文件，此時(shí)因?yàn)?code>npm install層的上層依賴變更了，哪怕依賴沒有進(jìn)行任何變動(dòng)，緩存也不會(huì)被復(fù)用。

因此，若想盡可能的利用上npm install層緩存，我們可以把 Dockerfile 改成這樣：

COPY?package*.json?.
RUN?npm?install
COPY?src?.

這樣在僅變更源碼時(shí)，node_modules的依賴緩存仍然能被利用上了。

由此，我們得到了優(yōu)化原則：

• 最小化處理變更文件，僅變更下一步所需的文件，以盡可能減少構(gòu)建過程中的緩存失效。

• 對(duì)于處理文件變更的 ADD 命令、COPY 命令，盡量延遲執(zhí)行。

構(gòu)建體積優(yōu)化

在保證速度的前提下，體積優(yōu)化也是我們需要去考慮的。這里我們需要考慮的有三點(diǎn)：

• Docker 是以層為單位上傳鏡像倉庫的，這樣也能最大化的利用緩存的能力。因此，執(zhí)行結(jié)果很少變化的命令需要抽出來單獨(dú)成層，如上面提到的npm install的例子里，也用到了這方面的思想。

• 如果鏡像層數(shù)越少，總上傳體積就越小。因此，在命令處于執(zhí)行鏈尾部，即不會(huì)對(duì)其他層緩存產(chǎn)生影響的情況下，盡量合并命令，從而減少緩存體積。例如，設(shè)置環(huán)境變量和清理無用文件的指令，它們的輸出都是不會(huì)被使用的，因此可以將這些命令合并為一行 RUN 命令。

RUN?set?ENV=prod?&&?rm?-rf?./trash

3. Docker cache 的下載也是通過層緩存的方式，因此為了減少鏡像的傳輸下載時(shí)間，我們最好使用固定的物理機(jī)器來進(jìn)行構(gòu)建。例如在流水線中指定專用宿主機(jī)，能是的鏡像的準(zhǔn)備時(shí)間大大減少。

當(dāng)然，時(shí)間和空間的優(yōu)化從來就沒有兩全其美的辦法，這一點(diǎn)需要我們?cè)谠O(shè)計(jì) Dockerfile 時(shí)，對(duì) Docker Layer 層數(shù)做出權(quán)衡。例如為了時(shí)間優(yōu)化，需要我們拆分文件的復(fù)制等操作，而這一點(diǎn)會(huì)導(dǎo)致層數(shù)增多，略微增加空間。

這里我的建議是，優(yōu)先保證構(gòu)建時(shí)間，其次在不影響時(shí)間的情況下，盡可能的縮小構(gòu)建緩存體積。

以 Docker 的思維管理服務(wù)

避免使用進(jìn)程守護(hù)

我們編寫傳統(tǒng)的后臺(tái)服務(wù)時(shí)，總是會(huì)使用例如 pm2、forever 等等進(jìn)程守護(hù)程序，以保證服務(wù)在意外崩潰時(shí)能被監(jiān)測(cè)到并自動(dòng)重啟。但這一點(diǎn)在 Docker 下非但沒有益處，還帶來了額外的不穩(wěn)定因素。

首先，Docker 本身就是一個(gè)流程管理器，因此，進(jìn)程守護(hù)程序提供的崩潰重啟，日志記錄等等工作 Docker 本身或是基于 Docker 的編排程序（如 kubernetes）就能提供了，無需使用額外應(yīng)用實(shí)現(xiàn)。除此之外，由于守護(hù)進(jìn)程的特性，將不可避免的對(duì)于以下的情況產(chǎn)生影響：

• 增加進(jìn)程守護(hù)程序會(huì)使得占用的內(nèi)存增多，鏡像體積也會(huì)相應(yīng)增大。

• 由于守護(hù)進(jìn)程一直能正常運(yùn)行，服務(wù)發(fā)生故障時(shí)，Docker 自身的重啟策略將不會(huì)生效，Docker 日志里將不會(huì)記錄崩潰信息，排障溯源困難。

• 由于多了個(gè)進(jìn)程的加入，Docker 提供的 CPU、內(nèi)存等監(jiān)控指標(biāo)將變得不準(zhǔn)確。

因此，盡管 pm2 這樣的進(jìn)程守護(hù)程序提供了能夠適配 Docker 的版本：pm2-runtime，但我仍然不推薦大家使用進(jìn)程守護(hù)程序。

其實(shí)這一點(diǎn)其實(shí)是源自于我們的固有思想而犯下的錯(cuò)誤。在服務(wù)上云的過程中，難點(diǎn)其實(shí)不僅僅在于寫法與架構(gòu)上的調(diào)整，開發(fā)思路的轉(zhuǎn)變才是最重要的，我們會(huì)在上云的過程中更加深刻體會(huì)到這一點(diǎn)。

日志的持久化存儲(chǔ)

無論是為了排障還是審計(jì)的需要，后臺(tái)服務(wù)總是需要日志能力。按照以往的思路，我們將日志分好類后，統(tǒng)一寫入某個(gè)目錄下的日志文件即可。但是在 Docker 中，任何本地文件都不是持久化的，會(huì)隨著容器的生命周期結(jié)束而銷毀。因此，我們需要將日志的存儲(chǔ)跳出容器之外。

最簡(jiǎn)單的做法是利用 Docker Manager Volume，這個(gè)特性能繞過容器自身的文件系統(tǒng)，直接將數(shù)據(jù)寫到宿主物理機(jī)器上。具體用法如下：

docker?run?-d?-it?--name=app?-v?/app/log:/usr/share/log?app

運(yùn)行 docker 時(shí)，通過-v 參數(shù)為容器綁定 volumes，將宿主機(jī)上的 /app/log 目錄（如果沒有會(huì)自動(dòng)創(chuàng)建）掛載到容器的 /usr/share/log 中。這樣服務(wù)在將日志寫入該文件夾時(shí)，就能持久化存儲(chǔ)在宿主機(jī)上，不隨著 docker 的銷毀而丟失了。

當(dāng)然，當(dāng)部署集群變多后，物理宿主機(jī)上的日志也會(huì)變得難以管理。此時(shí)就需要一個(gè)服務(wù)編排系統(tǒng)來統(tǒng)一管理了。從單純管理日志的角度出發(fā)，我們可以進(jìn)行網(wǎng)絡(luò)上報(bào)，給到云日志服務(wù)（如騰訊云 CLS）托管。或者干脆將容器進(jìn)行批量管理，例如Kubernetes這樣的容器編排系統(tǒng)，這樣日志作為其中的一個(gè)模塊自然也能得到妥善保管了。這樣的方法很多，就不多加贅述了。

k8s 服務(wù)控制器的選擇

鏡像優(yōu)化之外，服務(wù)編排以及控制部署的負(fù)載形式對(duì)性能的影響也很大。這里以最流行的Kubernetes的兩種控制器（Controller）：Deployment 與 StatefulSet 為例，簡(jiǎn)要比較一下這兩類組織形式，幫助選擇出最適合服務(wù)的 Controller。

StatefulSet是 K8S 在 1.5 版本后引入的 Controller，主要特點(diǎn)為：能夠?qū)崿F(xiàn) pod 間的有序部署、更新和銷毀。那么我們的制品是否需要使用 StatefulSet 做 pod 管理呢？官方簡(jiǎn)要概括為一句話：

Deployment 用于部署無狀態(tài)服務(wù)，StatefulSet 用來部署有狀態(tài)服務(wù)。

這句話十分精確，但不易于理解。那么，什么是無狀態(tài)呢？在我看來，StatefulSet的特點(diǎn)可以從如下幾個(gè)步驟進(jìn)行理解：

• StatefulSet管理的多個(gè) pod 之間進(jìn)行部署，更新，刪除操作時(shí)能夠按照固定順序依次進(jìn)行。適用于多服務(wù)之間有依賴的情況，如先啟動(dòng)數(shù)據(jù)庫服務(wù)再開啟查詢服務(wù)。

• 由于 pod 之間有依賴關(guān)系，因此每個(gè) pod 提供的服務(wù)必定不同，所以 StatefulSet 管理的 pod 之間沒有負(fù)載均衡的能力。

• 又因?yàn)?pod 提供的服務(wù)不同，所以每個(gè) pod 都會(huì)有自己獨(dú)立的存儲(chǔ)空間，pod 間不共享。

• 為了保證 pod 部署更新時(shí)順序，必須固定 pod 的名稱，因此不像 Deployment 那樣生成的 pod 名稱后會(huì)帶一串隨機(jī)數(shù)。

• Le nom du pod étant fixe, le Service connecté à StatefulSet peut directement utiliser le nom du pod comme nom de domaine d'accès sans fournir l'IP du cluster code> code>, donc le <code>Service connecté à StatefulSet est appelé Headless Service. StatefulSet 對(duì)接的 Service 中可以直接以 pod 名稱作為訪問域名，而不需要提供Cluster IP，因此跟 StatefulSet 對(duì)接的 Service 被稱為 Headless Service。

通過這里我們就應(yīng)該明白，如果在 k8s 上部署的是單個(gè)服務(wù)，或是多服務(wù)間沒有依賴關(guān)系，那么 Deployment 一定是簡(jiǎn)單而又效果最佳的選擇，自動(dòng)調(diào)度，自動(dòng)負(fù)載均衡。而如果服務(wù)的啟停必須滿足一定順序，或者每一個(gè) pod 所掛載的數(shù)據(jù) volume 需要在銷毀后依然存在，那么建議選擇 StatefulSet。

本著如無必要，勿增實(shí)體的原則，強(qiáng)烈建議所有運(yùn)行單個(gè)服務(wù)工作負(fù)載采用 Deployment

Grace à cela, nous devons comprendre que si un seul service est déployé sur k8, ou s'il n'y a pas de dépendances entre plusieurs services, alors le Déploiement doit être simple et avoir la meilleure sélection d'effet, planification automatique, équilibrage automatique de la charge. Si le démarrage et l'arrêt des services doivent respecter une certaine séquence, ou si le volume de données monté sur chaque pod doit toujours exister après la destruction, il est alors recommandé de choisir StatefulSet. Conformément au principe de ne pas ajouter d'entités sauf si nécessaire, il est fortement recommandé que toutes les charges de travail exécutant un seul service utilisent Déploiement comme contr?leur.

écrit à la fin

Après l'avoir étudié, j'ai presque oublié l'objectif du début, j'ai donc rapidement reconstruit Docker pour voir les résultats de l'optimisation.

On peut voir que l'effet d'optimisation sur le volume de l'image est toujours bon, atteignant environ 10 fois. Bien entendu, si le projet ne nécessite pas une version aussi élevée de prise en charge des n?uds, la taille de l'image peut être encore réduite d'environ la moitié.

L'entrep?t miroir compressera ensuite les fichiers image stockés, et la version de l'image fournie avec node14 sera finalement compressée à moins de 50?Mo.

Bien s?r, outre les données de volume visibles, l'optimisation la plus importante réside en fait dans la transformation des services physiques orientés machine vers les services cloud conteneurisés au niveau de la conception architecturale. La conteneurisation est déjà l'avenir visible. En tant que développeur, vous devez toujours rester sensible aux technologies de pointe et les pratiquer activement afin de transformer la technologie en productivité et contribuer à l'évolution du projet.

??Pour plus de connaissances sur les n?uds, veuillez visiter?: ??tutoriel Nodejs???! ??

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!