יצירת שרשרת CI/CD ואוטומציה של עבודה עם Docker

את האתרים הראשונים שלי כתבתי בסוף שנות ה-90. אז היה קל מאוד להכניס אותם למצב תקין. היה שרת Apache באירוח משותף כלשהו, ​​אתה יכול להיכנס לשרת הזה באמצעות FTP על ידי כתיבת משהו כמו ftp://ftp.example.com. לאחר מכן היה עליך להזין את השם והסיסמה שלך ולהעלות את הקבצים לשרת. היו זמנים אחרים, הכל היה פשוט יותר אז מאשר עכשיו.

בשני העשורים שחלפו מאז הכל השתנה מאוד. אתרי אינטרנט הפכו מורכבים יותר; יש להרכיב אותם לפני שהם יוצאים לייצור. שרת בודד הפך לשרתים רבים הפועלים מאחורי מאזני עומסים, והשימוש במערכות בקרת גרסאות הפך לנפוץ.

לפרויקט האישי שלי הייתה לי תצורה מיוחדת. וידעתי שאני צריך את היכולת לפרוס את האתר בייצור על ידי ביצוע פעולה אחת בלבד: כתיבת קוד לסניף master ב-GitHub. בנוסף, ידעתי שכדי להבטיח את פעולת אפליקציית האינטרנט הקטנה שלי, אני לא רוצה לנהל אשכול Kubernetes ענק, או להשתמש בטכנולוגיית Docker Swarm, או לתחזק צי שרתים עם פודים, סוכנים ועוד כל מיני דברים אחרים. מורכבויות. על מנת להשיג את המטרה להפוך את העבודה לקלה ככל האפשר, הייתי צריך להכיר את CI/CD.

אם יש לך פרויקט קטן (במקרה הזה, פרויקט Node.js) ואתה רוצה לדעת איך להפוך את הפריסה של הפרויקט הזה לאוטומטי, תוך הקפדה על מה שמאוחסן במאגר מתאים בדיוק למה שעובד בייצור, אז אני חושב שאתה עשוי להתעניין במאמר זה.

תנאים מוקדמים

הקורא של מאמר זה צפוי להיות בעל הבנה בסיסית של שורת הפקודה וכתיבת סקריפטים של Bash. בנוסף, הוא יצטרך חשבונות טרוויס CI и רכזת דוקר.

מטרות

אני לא אגיד שאפשר לקרוא למאמר הזה ללא תנאי "הדרכה". זה יותר מסמך בו אני מדבר על מה שלמדתי ומתאר את התהליך שמתאים לי לבדיקה ופריסה של קוד לייצור, המתבצע במעבר אוטומטי אחד.

זה בסופו של דבר זרימת העבודה שלי.

עבור קוד שנשלח לכל סניף מאגר למעט master, מתבצעות הפעולות הבאות:

• הפרויקט שנבנה על Travis CI מתחיל.
• כל בדיקות היחידה, האינטגרציה ומקצה לקצה מבוצעות.

רק לקוד שנכנס לתוכו master, מתבצעות הפעולות הבאות:

• כל מה שהוזכר לעיל, בנוסף...
• בניית תמונת Docker על סמך הקוד, ההגדרות והסביבה הנוכחיים.
• פריסת התמונה ל- Docker Hub.
• חיבור לשרת הייצור.
• העלאת תמונה מ- Docker Hub לשרת.
• עצירת המכולה הנוכחית והתחלת מיכל חדש על סמך התמונה החדשה.

אם אתה לא יודע כלום על Docker, תמונות ומכולות, אל תדאג. אני אספר לך הכל על זה.

מה זה CI/CD?

הקיצור CI/CD מייצג "שילוב מתמשך/פריסה מתמשכת".

▍ אינטגרציה רציפה

אינטגרציה מתמשכת היא תהליך שבו מפתחים מתחייבים למאגר קוד המקור הראשי של הפרויקט (בדרך כלל סניף master). יחד עם זאת, איכות הקוד מובטחת באמצעות בדיקות אוטומטיות.

▍ פריסה רציפה

פריסה רציפה היא פריסה אוטומטית תכופה של קוד לייצור. החלק השני של ראשי התיבות CI/CD מאוית לפעמים כ"מסירה רציפה". זה בעצם זהה ל"פריסה רציפה", אבל "מסירה רציפה" מרמזת על הצורך לאשר שינויים באופן ידני לפני תחילת תהליך פריסת הפרויקט.

תחילת העבודה

האפליקציה שבה השתמשתי כדי ללמוד את כל זה נקראת לקחת הערה. זהו פרויקט אינטרנט שאני עובד עליו, המיועד לרישום הערות. בהתחלה ניסיתי לעשות JAMStack-פרויקט, או סתם יישום חזיתי ללא שרת, על מנת לנצל את יכולות האירוח הסטנדרטיות ופריסה של פרויקטים שהיא מציעה נטליפיי. ככל שהמורכבות של האפליקציה גדלה, הייתי צריך ליצור את חלק השרת שלה, מה שאומר שאצטרך לגבש אסטרטגיה משלי לאינטגרציה אוטומטית ופריסה אוטומטית של הפרויקט.

במקרה שלי, האפליקציה היא שרת אקספרס הפועל בסביבת Node.js, המשרתת אפליקציית React של עמוד בודד ותומך ב-API מאובטח בצד השרת. ארכיטקטורה זו עוקבת אחר האסטרטגיה שניתן למצוא בה זה מדריך אימות ערימה מלאה.

התייעצתי עם другом, שהוא מומחה לאוטומציה, ושאל אותו מה אני צריך לעשות כדי שהכל יעבוד כמו שרציתי. הוא נתן לי את הרעיון של איך צריך להיראות זרימת עבודה אוטומטית, המתואר בסעיף היעדים של מאמר זה. משמעות המטרות האלה היא שהייתי צריך להבין איך להשתמש ב- Docker.

סַוָר

Docker הוא כלי שבזכות טכנולוגיית קונטיינריזציה מאפשר הפצה, פריסה והפעלה של אפליקציות בקלות באותה סביבה, גם אם פלטפורמת Docker עצמה פועלת בסביבות שונות. ראשית, הייתי צריך לשים את ידי על כלי שורת הפקודה של Docker (CLI). הוראה מדריך ההתקנה של Docker לא יכול להיקרא מאוד ברור ומובן, אבל ממנו ניתן ללמוד שכדי לבצע את שלב ההתקנה הראשון, צריך להוריד את Docker Desktop (ל-Mac או Windows).

Docker Hub הוא בערך אותו דבר כמו GitHub עבור מאגרי git, או רישום Npm עבור חבילות JavaScript. זהו מאגר מקוון לתמונות Docker. לזה מתחבר Docker Desktop.

אז כדי להתחיל עם Docker, אתה צריך לעשות שני דברים:

• להתקין שולחני Docker.
• להירשם ל רכזת דוקר.

לאחר מכן, אתה יכול לבדוק אם Docker CLI פועל על ידי הפעלת הפקודה הבאה כדי לבדוק את גרסת Docker:

docker -v

לאחר מכן, היכנס ל- Docker Hub על ידי הזנת שם המשתמש והסיסמה שלך כאשר תתבקש:

docker login

כדי להשתמש ב-Docker, עליך להבין את המושגים של תמונות ומכולות.

▍תמונות

תמונה היא משהו כמו שרטוט שמכיל הוראות להרכבת המיכל. זוהי תמונת מצב בלתי ניתנת לשינוי של מערכת הקבצים וההגדרות של היישום. מפתחים יכולים לשתף תמונות בקלות.

# Вывод сведений обо всех образах
docker images

פקודה זו תוציא טבלה עם הכותרת הבאה:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

לאחר מכן נסתכל על כמה דוגמאות של פקודות באותו פורמט - ראשית יש פקודה עם הערה, ואחר כך דוגמה למה שהיא יכולה להוציא.

▍מכולות

קונטיינר הוא חבילת הפעלה המכילה את כל הדרוש להפעלת יישום. אפליקציה בגישה זו תעבוד תמיד אותו הדבר, ללא קשר לתשתית: בסביבה מבודדת ובאותה סביבה. הנקודה היא שמופעים של אותה תמונה מושקים בסביבות שונות.

# Перечисление всех контейнеров
docker ps -a
CONTAINER ID     IMAGE     COMMAND     CREATED     STATUS     PORTS     NAMES
---

▍תגים

תג הוא אינדיקציה לגרסה מסוימת של תמונה.

▍הפניה מהירה לפקודות Docker

להלן סקירה כללית של כמה פקודות Docker הנפוצות.

קבוצה

הֶקשֵׁר

אפקט

בניית docker

תמונה

בניית תמונה מתוך Dockerfile

תג docker

תמונה

תיוג תמונה

תמונות מעגן

תמונה

תמונות רישום

מעגן לרוץ

מכולה

הפעלת מיכל המבוסס על תמונה

לדחוף דוקר

תמונה

העלאת תמונה לרישום

משיכת דוקר

תמונה

טעינת תמונה מהרישום

מעגן

מכולה

רישום מכולות

גזם מערכת docker

תמונה/מיכל

הסרת מיכלים ותמונות שאינם בשימוש

▍Dockerfile

אני יודע להפעיל יישום ייצור מקומי. יש לי תצורת Webpack שנועדה לבנות אפליקציית React מוכנה. לאחר מכן, יש לי פקודה שמתחילה שרת מבוסס Node.js ביציאה 5000. זה נראה כמו זה:

npm i         # установка зависимостей
npm run build # сборка React-приложения
npm run start # запуск Node-сервера

יש לציין שאין לי אפליקציה לדוגמה לחומר זה. אבל כאן, עבור ניסויים, כל יישום פשוט של Node יתאים.

על מנת להשתמש במיכל, תצטרך לתת הוראות ל-Docker. זה נעשה באמצעות קובץ בשם Dockerfile, הממוקם בספריית הבסיס של הפרויקט. הקובץ הזה, בהתחלה, נראה די לא מובן.

אבל מה שהוא מכיל רק מתאר, עם פקודות מיוחדות, משהו הדומה להקמת סביבת עבודה. הנה כמה מהפקודות האלה:

• מן - פקודה זו מתחילה קובץ. הוא מציין את תמונת הבסיס שעליה בנויה המכולה.
• COPY - העתקת קבצים ממקור מקומי למיכל.
• WORKDIR — הגדרת ספריית העבודה עבור הפקודות הבאות.
• לָרוּץ - הפעל פקודות.
• לַחשׂוֹף — הגדרות יציאה.
• נקודת כניסה - ציון הפקודה שיש לבצע.

Dockerfile יכול להיראות משהו כזה:

# Загрузить базовый образ
FROM node:12-alpine

# Скопировать файлы из текущей директории в директорию app/
COPY . app/

# Использовать app/ в роли рабочей директории
WORKDIR app/

# Установить зависимости (команда npm ci похожа npm i, но используется для автоматизированных сборок)
RUN npm ci --only-production

# Собрать клиентское React-приложение для продакшна
RUN npm run build

# Прослушивать указанный порт
EXPOSE 5000

# Запустить Node-сервер
ENTRYPOINT npm run start

בהתאם לתמונת הבסיס שתבחר, ייתכן שיהיה עליך להתקין תלות נוספת. העובדה היא שכמה תמונות בסיס (כמו Node Alpine Linux) נוצרות במטרה להפוך אותן לקומפקטיות ככל האפשר. כתוצאה מכך, ייתכן שלא יהיו להם חלק מהתוכניות שאתה מצפה.

▍בנייה, תיוג והפעלת המכולה

הרכבה מקומית והשקה של המכולה היא לאחר שיש לנו Dockerfile, המשימות די פשוטות. לפני שאתה דוחף את התמונה ל- Docker Hub, עליך לבדוק אותה באופן מקומי.

▍הרכבה

ראשית אתה צריך לאסוף תמונה, ציון שם ולחלופין, תג (אם לא צוין תג, המערכת תקצה אוטומטית תג לתמונה latest).

# Сборка образа
docker build -t <image>:<tag> .

לאחר הפעלת פקודה זו, אתה יכול לראות את Docker בונה את התמונה.

Sending build context to Docker daemon   2.88MB
Step 1/9 : FROM node:12-alpine
 ---> ...выполнение этапов сборки...
Successfully built 123456789123
Successfully tagged <image>:<tag>

הבנייה עשויה להימשך כמה דקות - הכל תלוי בכמה תלות יש לך. לאחר השלמת הבנייה, תוכל להפעיל את הפקודה docker images והסתכל על התיאור של התמונה החדשה שלך.

REPOSITORY          TAG               IMAGE ID            CREATED              SIZE
<image>             latest            123456789123        About a minute ago   x.xxGB

▍השקה

התמונה נוצרה. זה אומר שאתה יכול להפעיל קונטיינר המבוסס על זה. כי אני רוצה להיות מסוגל לגשת לאפליקציה הפועלת בקונטיינר ב localhost:5000, אני, בצד שמאל של הזוג 5000:5000 בפקודה הבאה שהותקנה 5000. בצד ימין נמצא יציאת המכולות.

# Запуск с использованием локального порта 5000 и порта контейнера 5000
docker run -p 5000:5000 <image>:<tag>

כעת לאחר שהמכל נוצר ופועל, אתה יכול להשתמש בפקודה docker ps כדי להסתכל על מידע על מיכל זה (או שאתה יכול להשתמש בפקודה docker ps -a, שמציג מידע על כל הקונטיינרים, לא רק אלה הפועלים).

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS                    NAMES
987654321234        <image>             "/bin/sh -c 'npm run…"   6 seconds ago        Up 6 seconds                0.0.0.0:5000->5000/tcp   stoic_darwin

אם אתה הולך עכשיו לכתובת localhost:5000 - אתה יכול לראות עמוד של יישום פועל שנראה בדיוק כמו הדף של יישום הפועל בסביבת ייצור.

▍תיוג ופרסום

על מנת להשתמש באחת מהתמונות שנוצרו בשרת הייצור, עלינו להיות מסוגלים להוריד תמונה זו מ- Docker Hub. משמעות הדבר היא שתחילה עליך ליצור מאגר עבור הפרויקט ב- Docker Hub. לאחר מכן, יהיה לנו מקום בו נוכל לשלוח את התמונה. יש לשנות את שמה של התמונה כך ששמה יתחיל בשם המשתמש שלנו ב- Docker Hub. אחרי זה צריך להיות שם המאגר. ניתן למקם כל תג בסוף השם. להלן דוגמה למתן שמות לתמונות באמצעות סכימה זו.

עכשיו אתה יכול לבנות את התמונה עם שם חדש ולהפעיל את הפקודה docker push כדי לדחוף אותו למאגר Docker Hub.

docker build -t <username>/<repository>:<tag> .
docker tag <username>/<repository>:<tag> <username>/<repository>:latest
docker push <username>/<repository>:<tag>

# На практике это может выглядеть, например, так:
docker build -t user/app:v1.0.0 .
docker tag user/app:v1.0.0 user/app:latest
docker push user/app:v1.0.0

אם הכל ילך כשורה, התמונה תהיה זמינה ב- Docker Hub וניתן להעלות אותה בקלות לשרת או להעביר אותה למפתחים אחרים.

השלבים הבאים

עד עכשיו אימתנו שהאפליקציה, בצורה של קונטיינר Docker, פועלת באופן מקומי. העלינו את הקונטיינר ל- Docker Hub. כל זה אומר שכבר התקדמנו מאוד לקראת המטרה שלנו. כעת עלינו לפתור שתי שאלות נוספות:

• הגדרת כלי CI לבדיקה ופריסה של קוד.
• הגדרת שרת הייצור כך שיוכל להוריד ולהפעיל את הקוד שלנו.

במקרה שלנו, אנחנו משתמשים טרוויס CI. בתור שרת - דיטיגל אושן.

יש לציין כי כאן ניתן להשתמש בשילוב אחר של שירותים. לדוגמה, במקום Travis CI, אתה יכול להשתמש ב-CircleCI או ב-Github Actions. ובמקום DigitalOcean - AWS או Linode.

החלטנו לעבוד עם Travis CI, וכבר יש לי משהו מוגדר בשירות הזה. לכן, עכשיו אדבר בקצרה על איך להכין אותו לעבודה.

טרוויס CI

Travis CI הוא כלי לבדיקה ופריסה של קוד. לא הייתי רוצה להיכנס למורכבות של הקמת Travis CI, שכן כל פרויקט הוא ייחודי, וזה לא יביא הרבה תועלת. אבל אני אכסה את היסודות כדי להתחיל בעבודה אם תחליט להשתמש ב-Travis CI. בין אם תבחרו ב-Travis CI, CircleCI, Jenkins או משהו אחר, שיטות תצורה דומות ישמשו בכל מקום.

כדי להתחיל עם Travis CI, עבור אל אתר הפרויקט וליצור חשבון. לאחר מכן שלב את Travis CI עם חשבון GitHub שלך. בעת הגדרת המערכת, יהיה עליך לציין את המאגר איתו תרצה להפוך את העבודה לאוטומטי ולאפשר גישה אליו. (אני משתמש ב-GitHub, אבל אני בטוח ש-Travis CI יכול להשתלב עם BitBucket, ו-GitLab ושירותים דומים אחרים).

בכל פעם ש-Travis CI מופעל, השרת מופעל, תוך ביצוע הפקודות המצוינות בקובץ התצורה, כולל פריסת ענפי המאגר המתאימים.

▍מחזור חיים של עבודה

קובץ התצורה של Travis CI נקרא .travis.yml ומאוחסן בספריית השורש של הפרויקט, תומך בקונספט של אירועים מעגל החיים משימות. אירועים אלה רשומים לפי סדר התרחשותם:

• apt addons
• cache components
• before_install
• install
• before_script
• script
• before_cache
• after_success или after_failure
• before_deploy
• deploy
• after_deploy
• after_script

▍בדיקות

בקובץ התצורה אני הולך להגדיר את שרת Travis CI המקומי. בחרתי ב-Node 12 כשפה ואמרתי למערכת להתקין את התלות הנדרשת כדי להשתמש ב-Docker.

כל מה שרשום ב .travis.yml, יבוצע כאשר כל בקשות המשיכה יבוצעו לכל הסניפים של המאגר, אלא אם צוין אחרת. זוהי תכונה שימושית כי זה אומר שאנחנו יכולים לבדוק את כל הקוד שנכנס למאגר. זה מאפשר לך לדעת אם הקוד מוכן להיכתב לסניף. master, והאם זה ישבור את תהליך בניית הפרויקט. בתצורה הגלובלית הזו, אני מתקין הכל באופן מקומי, מריץ את שרת הפיתוח של Webpack ברקע (זוהי תכונה של זרימת העבודה שלי), ומבצע בדיקות.

אם אתה רוצה שהמאגר שלך יציג תגים המציינים כיסוי בדיקה, כאן תוכל למצוא הוראות קצרות לשימוש ב-Jest, Travis CI וסרבל לאיסוף ולהצגה של מידע זה.

אז הנה תוכן הקובץ .travis.yml:

# Установить язык
language: node_js

# Установить версию Node.js
node_js:
  - '12'

services:
  # Использовать командную строку Docker
  - docker

install:
  # Установить зависимости для тестов
  - npm ci

before_script:
  # Запустить сервер и клиент для тестов
  - npm run dev &

script:
  # Запустить тесты
  - npm run test

כאן מסתיימות הפעולות שמתבצעות עבור כל ענפי המאגר ועבור בקשות משיכה.

▍ פריסה

בהתבסס על ההנחה שכל הבדיקות האוטומטיות הסתיימו בהצלחה, אנחנו יכולים, וזה אופציונלי, לפרוס את הקוד לשרת הייצור. מכיוון שאנו רוצים לעשות זאת רק עבור קוד מהסניף master, אנו נותנים למערכת הוראות מתאימות בהגדרות הפריסה. לפני שתנסה להשתמש בקוד שנסתכל עליו בשלב הבא בפרויקט שלך, ברצוני להזהיר אותך שחייב להיות לך סקריפט אמיתי שנקרא לפריסה.

deploy:
  # Собрать Docker-контейнер и отправить его на Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

סקריפט הפריסה פותר שתי בעיות:

• בנו, תייגו ושלחו את התמונה ל- Docker Hub באמצעות כלי CI (במקרה שלנו, Travis CI).
• טעינת התמונה על השרת, עצירת הקונטיינר הישן והתחלת קונטיינר חדש (במקרה שלנו, השרת פועל על פלטפורמת DigitalOcean).

ראשית, עליך להגדיר תהליך אוטומטי לבנייה, תיוג ודחיפת התמונה ל- Docker Hub. כל זה דומה מאוד למה שכבר עשינו באופן ידני, פרט לכך שאנחנו צריכים אסטרטגיה להקצאת תגים ייחודיים לתמונות ואוטומציה של כניסות. היה לי קושי עם כמה פרטים של סקריפט הפריסה, כגון אסטרטגיית תיוג, כניסה, קידוד מפתח SSH, יצירת חיבור SSH. אבל למזלי החבר שלי טוב מאוד עם bash, כמו עם הרבה דברים אחרים. הוא עזר לי לכתוב את התסריט הזה.

אז, החלק הראשון של התסריט הוא העלאת התמונה ל- Docker Hub. זה די קל לעשות. סכימת התיוג שבה השתמשתי כוללת שילוב של git hash ותג git, אם קיים כזה. זה מבטיח שהתג הוא ייחודי ומקל על זיהוי המכלול שעליו הוא מבוסס. DOCKER_USERNAME и DOCKER_PASSWORD הם משתני סביבת משתמש שניתן להגדיר באמצעות ממשק Travis CI. Travis CI יעבד אוטומטית נתונים רגישים כדי שלא ייפלו לידיים הלא נכונות.

הנה החלק הראשון של התסריט deploy.sh.

#!/bin/sh
set -e # Остановить скрипт при наличии ошибок

IMAGE="<username>/<repository>"                             # Образ Docker
GIT_VERSION=$(git describe --always --abbrev --tags --long) # Git-хэш и теги

# Сборка и тегирование образа
docker build -t ${IMAGE}:${GIT_VERSION} .
docker tag ${IMAGE}:${GIT_VERSION} ${IMAGE}:latest

# Вход в Docker Hub и выгрузка образа
echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
docker push ${IMAGE}:${GIT_VERSION}

מה יהיה החלק השני של הסקריפט תלוי לחלוטין באיזה מארח אתה משתמש ואיך החיבור אליו מאורגן. במקרה שלי, מכיוון שאני משתמש ב-Digital Ocean, אני משתמש בפקודות כדי להתחבר לשרת doctl. בעת עבודה עם AWS, כלי השירות ישמש aws, וכן הלאה.

הגדרת השרת לא הייתה קשה במיוחד. אז, הקמתי טיפה על סמך תמונת הבסיס. יש לציין שהמערכת שבחרתי דורשת התקנה ידנית חד פעמית של Docker והשקה ידנית חד פעמית של Docker. השתמשתי באובונטו 18.04 כדי להתקין את Docker, אז אם אתה גם משתמש באובונטו כדי לעשות את אותו הדבר, אתה יכול פשוט לעקוב זה מדריך פשוט.

אני לא מדבר כאן על פקודות ספציפיות לשירות, מכיוון שהיבט זה יכול להשתנות מאוד במקרים שונים. אני רק אתן תוכנית פעולה כללית שתתבצע לאחר התחברות באמצעות SSH לשרת עליו יתפרס הפרויקט:

• אנחנו צריכים למצוא את המכולה שפועלת כרגע ולעצור אותה.
• אז אתה צריך להפעיל מיכל חדש ברקע.
• יהיה עליך להגדיר את היציאה המקומית של השרת ל 80 - זה יאפשר לך להיכנס לאתר בכתובת כמו example.com, מבלי לציין את היציאה, במקום להשתמש בכתובת כמו example.com:5000.
• לבסוף, עליך למחוק את כל המכולות והתמונות הישנות.

הנה המשך התסריט.

# Найти ID работающего контейнера
CONTAINER_ID=$(docker ps | grep takenote | cut -d" " -f1)

# Остановить старый контейнер, запустить новый, очистить систему
docker stop ${CONTAINER_ID}
docker run --restart unless-stopped -d -p 80:5000 ${IMAGE}:${GIT_VERSION}
docker system prune -a -f

כמה דברים שצריך לשים לב אליהם

יתכן שכשתתחבר לשרת דרך SSH מ-Travis CI תראה אזהרה שתמנע ממך להמשיך בהתקנה שכן המערכת תחכה לתגובת המשתמש.

The authenticity of host '<hostname> (<IP address>)' can't be established.
RSA key fingerprint is <key fingerprint>.
Are you sure you want to continue connecting (yes/no)?

למדתי שניתן לקודד מפתח מחרוזת ב-base64 על מנת לשמור אותו בצורה שבה ניתן לעבוד איתו בצורה נוחה ואמינה. בשלב ההתקנה, ניתן לפענח את המפתח הציבורי ולכתוב אותו לקובץ known_hosts על מנת להיפטר מהשגיאה לעיל.

echo <public key> | base64 # выводит <публичный ключ, закодированный в base64>

בפועל, פקודה זו עשויה להיראות כך:

echo "123.45.67.89 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]" | base64

והנה מה שהוא מייצר - מחרוזת מקודדת base64:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

הנה הפקודה שהוזכרה למעלה

install:
  - echo < публичный ключ, закодированный в base64> | base64 -d >> $HOME/.ssh/known_hosts

ניתן להשתמש באותה גישה עם מפתח פרטי בעת יצירת חיבור, שכן ייתכן שתזדקק למפתח פרטי כדי לגשת לשרת. כשאתה עובד עם המפתח, אתה רק צריך לוודא שהוא מאוחסן בצורה מאובטחת במשתנה סביבת Travis CI ושהוא לא יוצג בשום מקום.

דבר נוסף שיש לציין הוא שייתכן שתצטרך להריץ את כל סקריפט הפריסה כשורה אחת, למשל - עם doctl. זה עשוי לדרוש מאמץ נוסף.

doctl compute ssh <droplet> --ssh-command "все команды будут здесь && здесь"

TLS/SSL ואיזון עומסים

אחרי שעשיתי את כל מה שהוזכר לעיל, הבעיה האחרונה שנתקלתי בה הייתה שלשרת לא היה SSL. מאז אני משתמש בשרת Node.js, על מנת להכריח работать פרוקסי הפוך Nginx ו-Let's Encrypt, אתה צריך להתעסק הרבה.

ממש לא רציתי לעשות את כל תצורת ה-SSL הזו באופן ידני, אז פשוט יצרתי מאזן עומסים ורשמתי את הפרטים שלו ב-DNS. במקרה של DigitalOcean, למשל, יצירת תעודה בחתימה עצמית לחידוש אוטומטי על מאזן העומס היא הליך פשוט, חינמי ומהיר. לגישה זו יתרון נוסף שהיא מקלה מאוד על הגדרת SSL במספר שרתים הפועלים מאחורי מאזן עומסים במידת הצורך. זה מאפשר לשרתים עצמם לא "לחשוב" על SSL בכלל, אבל באותו זמן להשתמש בפורט כרגיל 80. אז הגדרת SSL על איזון עומסים היא הרבה יותר קלה ונוחה משיטות חלופיות להגדרת SSL.

כעת ניתן לסגור את כל הפורטים בשרת שמקבלים חיבורים נכנסים - מלבד הפורט 80, משמש לתקשורת עם מאזן העומס והיציאה 22 עבור SSH. כתוצאה מכך, ניסיון לגשת ישירות לשרת ביציאות אחרות מלבד שתי אלה ייכשל.

תוצאות של

אחרי שעשיתי את כל מה שדיברתי עליו בחומר הזה, לא הפלטפורמה של Docker ולא המושגים של רשתות CI/CD אוטומטיות הפחידו אותי יותר. הצלחתי להגדיר שרשרת אינטגרציה רציפה, שבמהלכה נבדק הקוד לפני שהוא נכנס לייצור והקוד נפרס אוטומטית בשרת. כל זה עדיין חדש יחסית עבורי, ואני בטוח שיש דרכים לשפר את זרימת העבודה האוטומטית שלי ולהפוך אותה ליעילה יותר. אז אם יש לך רעיונות בעניין הזה, אנא הודע לי. לי לָדַעַת. אני מקווה שמאמר זה עזר לך במאמציך. אני רוצה להאמין שאחרי שקראת אותו, למדת הרבה כמו שאני למדתי תוך כדי הבנת כל מה שדיברתי עליו.

נ.ב. שלנו זירת מסחר יש תמונה סַוָר, שניתן להתקין בקליק אחד. ניתן לבדוק את פעולת המכולות בכתובת VPS. כל הלקוחות החדשים מקבלים 3 ימי בדיקה ללא תשלום.

קוראים יקרים! האם אתה משתמש בטכנולוגיות CI/CD בפרויקטים שלך?

מקור: www.habr.com