GSP053

Огляд

У DevOps є різні сценарії розгортання додатків (безперервне, синьо-зелене, канаркове тощо), для яких регулярно використовуються кілька розгортань. Під час цієї практичної роботи ви навчитеся змінювати кількість контейнерів і керувати ними, щоб виконувати поширені сценарії з кількома гетерогенними розгортаннями.

Цілі

У цій практичній роботі ви навчитеся виконувати наведені нижче дії.

• Використовувати інструмент kubectl
• Створювати файли розгортання yaml
• Запускати, оновлювати й масштабувати розгортання
• Оновлювати розгортання й використовувати їх типи

Рівень попередньої підготовки

Результати практичної роботи будуть кращими, якщо ви:

• виконали такі практичні роботи з каталогу Google Cloud Skills Boost:
  • Початок роботи з Docker
  • Початок роботи з вузлами Kubernetes
• маєте навички системного адміністрування Linux;
• розумієте теорію DevOps і поняття безперервного розгортання.

Типи розгортань

Зазвичай гетерогенними вважаються розгортання, у яких через певну технічну чи операційну потребу поєднуються два або більше інфраструктурних середовищ чи регіонів. Залежно від особливостей такі розгортання також називають "гібридними", "мультихмарними" або "загальнодоступно-приватними".

У цій практичній роботі до гетерогенних розгортань належать ті, що вміщують кілька регіонів у єдиному хмарному середовищі, кілька загальнодоступних хмарних середовищ (мультихмарні) або поєднання локальних середовищ із загальнодоступними хмарними середовищами (гібридні або загальнодоступно-приватні).

У розгортаннях, які обмежені одним середовищем або регіоном, можуть виникати різні організаційні чи технічні проблеми.

• Брак ресурсів. За використання одного середовища (особливо якщо воно локальне) наявних обчислювальних і мережевих потужностей та сховища може не вистачити, щоб задовольнити ваші потреби.
• Обмежене географічне охоплення. Якщо розгортання відбувається в одному середовищі, географічно віддалені одне від одного користувачі отримуватимуть доступ до того самого розгортання. Можливо, їхньому трафіку доведеться подолати пів світу, перш ніж досягнути основного сервера.
• Обмежена доступність. Через те, що більша частина трафіку припадає на загальнодоступні мережі, додатки стають менш стійкими до помилок і збоїв.
• Перешкоди з боку постачальника. Абстрагування в інфраструктурі й на платформах постачальника можуть заважати вам портувати додатки.
• Негнучкі ресурси. У вас може бути недостатньо велике сховище, обмежені обчислювальні чи мережеві потужності.

Гетерогенні розгортання допомагають усувати такі проблеми, але при цьому потрібно використовувати програмовані й детерміновані процеси та процедури. Одноразові або нетипові процедури можуть робити розгортання вразливими й нестійкими до збоїв. Нетипові процеси можуть призводити до втрати даних чи зупинки трафіку. Варто застосовувати повторювані процеси розгортання, які використовують надійні підходи до керування розподіленням, конфігурацією і обслуговуванням.

Гетерогенні розгортання застосовуються в трьох основних сценаріях:

• мультихмарні розгортання;
• локальна інфраструктура даних;
• процеси безперервної інтеграції/розгортання.

За допомогою наведених далі вправ ви потренуєтеся виконувати поширені сценарії для гетерогенних розгортань, а також ознайомитеся з добре спроектованими підходами з використанням Kubernetes і іншими інфраструктурними ресурсами.

Налаштування й вимоги

Перш ніж натиснути кнопку Start Lab (Почати практичну роботу)

Ознайомтеся з наведеними нижче вказівками. На виконання практичної роботи відводиться обмежений час, і її не можна призупинити. Щойно ви натиснете Start Lab (Почати практичну роботу), з’явиться таймер, який показуватиме, скільки часу для роботи з ресурсами Google Cloud у вас залишилося.

Ви зможете виконати практичну роботу в дійсному робочому хмарному середовищі (не в симуляції або демонстраційному середовищі). Для цього на час виконання практичної роботи вам надаються тимчасові облікові дані для реєстрації і входу в Google Cloud.

Щоб виконати цю практичну роботу, потрібно мати:

• стандартний веб-переглядач, наприклад Chrome (рекомендовано)

Примітка. Виконуйте практичну роботу в режимі анонімного перегляду. Так ви уникнете додаткової плати, що може стягуватися з вашого особистого облікового запису внаслідок його конфліктів з обліковим записом для навчання.

• достатню кількість часу, оскільки почавши практичну роботу, ви не зможете призупинити її

Примітка. Якщо ви маєте особистий обліковий запис або проект Google Cloud, не використовуйте їх для доступу до цієї практичної роботи. Так ви уникнете додаткових стягнень з вашого облікового запису.

Як почати виконувати практичну роботу й увійти в Google Cloud Console

1. Натисніть кнопку Start Lab (Почати практичну роботу). Якщо за практичну роботу необхідно заплатити, відкриється спливаюче вікно, де ви зможете обрати спосіб оплати. Ліворуч розміщено панель Lab Details (Відомості про практичну роботу) з такими даними:

   • кнопка Open Google Cloud console (Відкрити Google Cloud Console);
   • час до закінчення;
   • тимчасові облікові дані, які потрібно використовувати для доступу до цієї практичної роботи;
   • інша інформація, необхідна для виконання цієї практичної роботи.

2. Натисніть Open Google Cloud console (Відкрити Google Cloud Console) або натисніть правою кнопкою миші й виберіть Open Link in Incognito Window (Відкрити посилання в анонімному вікні), якщо ви використовуєте вебпереглядач Chrome.

   Завантажаться необхідні ресурси. Потім відкриється нова вкладка зі сторінкою Sign in (Вхід).

   Порада. Упорядковуйте вкладки в окремих вікнах, розміщуючи їх поруч.

   Примітка. Якщо з’явиться вікно Choose an account (Виберіть обліковий запис), натисніть Use Another Account (Увійти в інший обліковий запис).

3. За потреби скопіюйте значення в полі Username (Ім’я користувача) нижче й вставте його у вікні Sign in (Вхід).

   {{{user_0.username | "Username"}}}

   Поле Username (Ім’я користувача) також можна знайти на панелі Lab Details (Відомості про практичну роботу).

4. Натисніть Next (Далі).

5. Скопіюйте значення в полі Password (Пароль) нижче й вставте його у вікні Welcome (Привітання).

   {{{user_0.password | "Password"}}}

   Поле Password (Пароль) також можна знайти на панелі Lab Details (Відомості про практичну роботу).

6. Натисніть Next (Далі).

   Важливо. Обов’язково використовуйте облікові дані, призначені для відповідної практичної роботи. Не використовуйте облікові дані Google Cloud. Примітка. Якщо ввійти у власний обліковий запис Google Cloud, може стягуватися додаткова плата.

7. Виконайте наведені нижче дії.

   • Прийміть Умови використання.
   • Не додавайте способи відновлення й двохетапну перевірку (оскільки це тимчасовий обліковий запис).
   • Не реєструйте безкоштовні пробні версії.

Через кілька секунд Google Cloud Console відкриється в новій вкладці.

Примітка. Щоб переглянути меню зі списком продуктів і сервісів Google Cloud, натисніть меню навігації вгорі ліворуч.

Як активувати Cloud Shell

Cloud Shell – це віртуальна машина з попередньо завантаженими інструментами для розробників. Вона містить головний каталог обсягом 5 ГБ постійної пам’яті й працює в середовищі Google Cloud. Cloud Shell надає доступ до ресурсів Google Cloud через командний рядок.

1. Угорі консолі Google Cloud натисніть Activate Cloud Shell (Активувати Cloud Shell) .

Щойно ви підключитеся, вас буде автентифіковано, а проект отримає ваш PROJECT_ID (ІДЕНТИФІКАТОР ПРОЕКТУ). Вивід міститиме рядок зі значенням PROJECT_ID (ІДЕНТИФІКАТОР ПРОЕКТУ) для цього сеансу:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud – це інструмент командного рядка для Google Cloud. Він входить у пакет Cloud Shell і підтримує функцію автозавершення клавішею TAB.

2. (Необов’язково) Щоб вивести поточне ім’я облікового запису, введіть таку команду:

gcloud auth list

3. Натисніть Authorize (Авторизувати).

4. Вихідні дані матимуть такий вигляд:

Вивід:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Необов’язково) Щоб вивести ідентифікатор проекту, введіть таку команду:

gcloud config list project

Вивід:

[core] project = <project_ID>

Приклад виводу:

[core] project = qwiklabs-gcp-44776a13dea667a6 Примітка. Щоб знайти повну документацію щодо gcloud, перегляньте посібник з інтерфейсу командного рядка gcloud у Google Cloud.

Налаштуйте зону

Налаштуйте робочу зону Google Cloud, виконавши наведену нижче команду. Вставте потрібну зону замість .

gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

Отримайте зразок коду для цієї практичної роботи

1. Отримайте зразок коду для створення й запуску контейнерів і розгортання:

gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestrate-with-kubernetes/kubernetes

2. Створіть кластер із 3 вузлів (це може зайняти кілька хвилин):

gcloud container clusters create bootcamp \ --machine-type e2-small \ --num-nodes 3 \ --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

Завдання 1. Вивчіть об’єкт розгортання

Для початку дізнайтеся більше про об’єкт розгортання.

1. Для цього виконайте команду explain в інструменті kubectl:

kubectl explain deployment

2. Щоб переглянути всі поля, скористайтеся параметром --recursive:

kubectl explain deployment --recursive

3. Ви можете запускати команду explain під час виконання будь-яких завдань практичної роботи, щоб краще зрозуміти структуру об’єкта розгортання й призначення окремих полів:

kubectl explain deployment.metadata.name

Завдання 2. Створіть розгортання

1. Оновіть файл конфігурації deployments/auth.yaml:

vi deployments/auth.yaml

2. Відкрийте редактор:

i

3. У розділі контейнерів розгортання замініть image на таке значення:

... containers: - name: auth image: "kelseyhightower/auth:1.0.0" ...

4. Збережіть файл auth.yaml. Для цього натисніть <Esc> і введіть:

:wq

5. Натисніть <Enter>. Тепер створіть просте розгортання. Перегляньте файл конфігурації розгортання:

cat deployments/auth.yaml

Вивід:

apiVersion: apps/v1 kind: Deployment metadata: name: auth spec: replicas: 1 selector: matchLabels: app: auth template: metadata: labels: app: auth track: stable spec: containers: - name: auth image: "kelseyhightower/auth:1.0.0" ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

Зверніть увагу, що розгортання створює одну копію і для контейнера auth використовується версія 1.0.0.

Коли ви виконаєте команду kubectl create, щоб створити розгортання auth, буде створено одну групу контейнерів, яка відповідає даним у маніфесті розгортання. Це означає, що ви можете збільшити кількість таких груп, змінивши число, указане в полі replicas.

6. Створіть об’єкт розгортання за допомогою команди kubectl create:

kubectl create -f deployments/auth.yaml

7. Щоб перевірити, чи об’єкт створено, виконайте команду:

kubectl get deployments

8. Коли розгортання буде готовим, Kubernetes створить для нього об’єкт ReplicaSet. Щоб перевірити, чи створено ReplicaSet, виконайте команду:

kubectl get replicasets

Має відображатися об’єкт ReplicaSet під назвою на зразок auth-xxxxxxx.

9. Перегляньте групи контейнерів, створених у межах розгортання. Разом з об’єктом ReplicaSet створюється одна група контейнерів:

kubectl get pods

Час створити сервіс для розгортання auth. Ви вже знайомі з файлами маніфесту сервісів, тому ми не будемо докладно їх описувати.

10. Щоб створити сервіс auth, використайте команду kubectl create:

kubectl create -f services/auth.yaml

11. Тепер зробіть те саме, щоб створити розгортання hello й надати до нього доступ:

kubectl create -f deployments/hello.yaml kubectl create -f services/hello.yaml

12. Ще раз виконайте цю дію, щоб створити розгортання frontend:

kubectl create secret generic tls-certs --from-file tls/ kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf kubectl create -f deployments/frontend.yaml kubectl create -f services/frontend.yaml Примітка. Ви створили для клієнтської частини об’єкт ConfigMap.

13. Отримайте зовнішню IP-адресу клієнтської частини й перейдіть за нею:

kubectl get services frontend Примітка. Заповнення поля External-IP для вашого сервісу може тривати кілька секунд. Це звичайне явище. Виконуйте наведену вище команду кожні кілька секунд, доки поле не буде заповнено. curl -ks https://<EXTERNAL-IP>

Ви отримаєте відповідь hello.

14. За допомогою функції шаблонів виводу в інструменті kubectl можна запускати команду curl в одному рядку:

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

Перевірка виконаного завдання

Щоб підтвердити виконання завдання, натисніть Підтвердити виконання нижче. Якщо ви правильно створили кластер і розгортання auth, hello й frontend, з’явиться оцінка.

Створити кластер Kubernetes і розгортання (auth, hello й frontend)

Масштабуйте розгортання

Створене розгортання можна масштабувати. Для цього оновіть поле spec.replicas.

1. Щоб переглянути пояснення цього поля, знову виконайте команду kubectl explain:

kubectl explain deployment.spec.replicas

2. Найпростіший спосіб оновити поле копій – використати команду kubectl scale:

kubectl scale deployment hello --replicas=5 Примітка. Щоб усі нові групи контейнерів запустилися, знадобиться близько однієї хвилини.

Після оновлення розгортання Kubernetes автоматично оновить об’єкт ReplicaSet і запустить нові групи контейнерів, щоб їх загалом стало 5.

3. Переконайтеся, що запущено 5 груп контейнерів hello:

kubectl get pods | grep hello- | wc -l

4. Тепер зменште масштаб додатка:

kubectl scale deployment hello --replicas=3

5. Знову переконайтеся, що запущено потрібну кількість груп контейнерів:

kubectl get pods | grep hello- | wc -l

Ви ознайомилися з розгортаннями Kubernetes, а також навчилися керувати групою контейнерів і змінювати їх кількість.

Завдання 3. Виконайте послідовне оновлення

Розгортання підтримують перехід на нову версію образу шляхом послідовного оновлення. Під час такого оновлення розгортання створює новий об’єкт ReplicaSet і поступово збільшує в ньому кількість копій, зменшуючи кількість копій у старому об’єкті ReplicaSet.

Запустіть послідовне оновлення

1. Щоб оновити розгортання, виконайте таку команду:

kubectl edit deployment hello

2. У розділі контейнерів розгортання замініть image на таке значення:

... containers: image: kelseyhightower/hello:2.0.0 ...

3. Натисніть Save (Зберегти), а потім Exit (Вийти).

Оновлене розгортання збережеться в кластері, і Kubernetes почне послідовне оновлення.

4. Перегляньте новий об’єкт ReplicaSet, створений у Kubernetes:

kubectl get replicaset

5. Ви також можете побачити новий запис в історії оновлень:

kubectl rollout history deployment/hello

Призупиніть послідовне оновлення

Якщо в процесі оновлення виникли проблеми, призупиніть його.

1. Щоб призупинити оновлення, виконайте таку команду:

kubectl rollout pause deployment/hello

2. Перевірте статус виконання оновлення:

kubectl rollout status deployment/hello

3. Ви також можете перевірити це безпосередньо для груп контейнерів:

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Відновіть послідовне оновлення

Якщо оновлення призупинено, одні групи контейнерів перейшли на нову версію, а інші залишилися на попередній.

1. Щоб продовжити оновлення, виконайте команду resume:

kubectl rollout resume deployment/hello

2. Коли оновлення завершиться, після виконання команди status ви маєте побачити наведений нижче вивід.

kubectl rollout status deployment/hello

Вивід:

deployment "hello" successfully rolled out

Поверніться на попередню версію

Уявіть, що в новій версії виявлено помилку. Через це всі користувачі, які підключатимуться до нових груп контейнерів, стикатимуться з проблемами.

Ви хочете повернутися на попередню версію, щоб знайти причину проблеми, усунути її і випустити виправлену версію.

1. Щоб повернутися до попередньої версії, виконайте команду rollout:

kubectl rollout undo deployment/hello

2. Перегляньте історію і переконайтеся, що ви повернулися до попередньої версії:

kubectl rollout history deployment/hello

3. Крім того, перевірте, чи всі групи контейнерів повернулися на попередню версію:

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Чудово! Ви навчилися повертатися до попередньої версії розгортання Kubernetes і оновлювати додатки без простою.

Завдання 4. Канаркові розгортання

Використовуйте цей тип розгортання, якщо працюєте на новим розгортанням і хочете протестувати його на невеликій аудиторії. Так ви зможете зробити певну зміну доступною для маленької групи користувачів і уникнете ризиків, пов’язаних із новими випусками.

Створіть канаркове розгортання

Канаркове розгортання складається з окремого розгортання нової версії і сервісу, який націлюється як на звичайне стабільне розгортання, так і на канаркове.

1. Спершу створіть канаркове розгортання для нової версії:

cat deployments/hello-canary.yaml

Вивід:

apiVersion: apps/v1 kind: Deployment metadata: name: hello-canary spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello track: canary # Use ver 2.0.0 so it matches version on service selector version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

2. Тепер створіть канаркове розгортання:

kubectl create -f deployments/hello-canary.yaml

3. Коли його буде створено, у вас має бути два розгортання: hello й hello-canary. Перевірте це за допомогою команди kubectl:

kubectl get deployments

У селекторі app:hello сервісу hello відображатимуться групи контейнерів обох розгортань: робочого й канаркового. Однак оскільки канаркове розгортання має менше груп контейнерів, воно показуватиметься меншій кількості користувачів.

Перевірте канаркове розгортання

1. Щоб перевірити, яка версія hello використовується, виконайте такий запит:

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

2. Виконайте цей запит кілька разів. Здебільшого має показуватися версія hello 1.0.0, а в деяких випадках (1/4 = 25%) – версія 2.0.0.

Перевірка виконаного завдання

Щоб підтвердити виконання завдання, натисніть Підтвердити виконання нижче. Якщо ви правильно створили канаркове розгортання, з’явиться оцінка.

Канаркове розгортання

Створення канаркових розгортань – відповідність сеансів

У цій практичній роботі канаркове розгортання могло обробляти будь-який запит, надісланий у сервіс Nginx. Але іноді потрібно зробити так, щоб користувач не натрапляв на канаркове розгортання. Наприклад, ви внесли зміни в інтерфейс і не хочете нікого спантеличити. У такому разі варто "закріпити" за користувачем певне розгортання.

Для цього можна створити сервіс із відповідністю сеансів. Так користувач завжди обслуговуватиметься тією самою версією. У прикладі нижче в знайомий вам код сервісу додано поле sessionAffinity зі значенням ClientIP. Запити від усіх клієнтів із незмінною ІР-адресою надсилатимуться до тієї самої версії додатка hello.

kind: Service apiVersion: v1 metadata: name: "hello" spec: sessionAffinity: ClientIP selector: app: "hello" ports: - protocol: "TCP" port: 80 targetPort: 80

Ми не перевірятимемо цей метод у практичній роботі, оскільки для цього потрібно виконати складні налаштування. Однак поле sessionAffinity варто використовувати під час створення робочих канаркових розгортань.

Завдання 5. Синьо-зелені розгортання

Послідовні оновлення дуже зручні, оскільки дають змогу повільно розгортати додаток із мінімальними накладними витратами, втратами продуктивності й часом простою. Однак бувають випадки, коли краще спочатку повністю розгорнути нову версію, а потім націлити на неї розподілювачі навантаження. У такому разі слід використовувати синьо-зелені розгортання.

Для цього методу Kubernetes створює два окремі розгортання: "синє" для старої версії і "зелене" для нової. Використовуйте наявне розгортання hello як "синю" версію. Доступ до розгортання надаватиметься через сервіс, який працюватиме як маршрутизатор. Коли "зелену" версію буде повністю розгорнуто, ви перейдете на неї, оновивши сервіс.

Примітка. Значний недолік синьо-зелених розгортань – це те, що для розміщення додатка знадобиться щонайменше вдвічі більше ресурсів у кластері. Тому переконайтеся, що маєте достатньо ресурсів, перш ніж розгортати обидві версії додатка одразу.

Сервіс

Візьміть за основу наявний сервіс hello й додайте в нього селектор app:hello, version: 1.0.0. Цей селектор буде таким самим, як і в наявному "синьому" розгортанні, але в "зеленому" розгортанні він відрізнятиметься, оскільки там використовується інша версія.

• Спершу оновіть сервіс:

kubectl apply -f services/hello-blue.yaml Примітка. Не звертайте уваги на попередження resource service/hello is missing, оскільки проблема усувається автоматично.

Оновлення за допомогою синьо-зеленого розгортання

Щоб виконати таке оновлення, створіть "зелене" розгортання для нової версії. Воно відрізнятиметься міткою версії і шляхом до образу.

apiVersion: apps/v1 kind: Deployment metadata: name: hello-green spec: replicas: 3 selector: matchLabels: app: hello template: metadata: labels: app: hello track: stable version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 resources: limits: cpu: 0.2 memory: 10Mi livenessProbe: httpGet: path: /healthz port: 81 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 15 timeoutSeconds: 5 readinessProbe: httpGet: path: /readiness port: 81 scheme: HTTP initialDelaySeconds: 5 timeoutSeconds: 1

1. Створіть "зелене" розгортання:

kubectl create -f deployments/hello-green.yaml

2. Коли "зелене" розгортання буде готовим і належним чином запуститься, перевірте, чи поточна версія 1.0.0 усе ще використовується:

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

3. Тепер переведіть сервіс на нову версію:

kubectl apply -f services/hello-green.yaml

4. Після оновлення одразу почне застосовуватися "зелене" розгортання. Ви можете перевірити, чи використовується нова версія:

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Відкочування до попередньої версії за допомогою синьо-зеленого розгортання

За потреби ви можете так само повернутися до попередньої версії.

1. Якщо "синє" розгортання все ще активне, просто переведіть сервіс на попередню версію:

kubectl apply -f services/hello-blue.yaml

2. Оновивши сервіс, ви відкотите його до попередньої версії. Знову перевірте, чи правильна версія використовується:

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Вам удалося! Ви навчилися створювати синьо-зелені розгортання й оновлювати додатки у випадку, коли потрібно перейти одразу на готову версію.

Вітаємо!

Ви розширили свій досвід роботи з інструментом командного рядка kubectl і навчилися створювати різні конфігурації розгортань у файлах YAML, щоб запускати, оновлювати й масштабувати розгортання. Це базове тренування, якого має бути достатньо, щоб застосовувати набуті навички в реальних завданнях у галузі DevOps.

Наступні кроки/Докладніше

• Шаблони розгортання в Kubernetes.

• Рішення й вказівки з DevOps у документації Google Cloud.

• Долучайтеся до спільноти Kubernetes!

Навчання й сертифікація Google Cloud

…допомагають ефективно використовувати технології Google Cloud. Наші курси передбачають опанування технічних навичок, а також ознайомлення з рекомендаціями, що допоможуть вам швидко зорієнтуватися й вивчити матеріал. Ми пропонуємо курси різних рівнів – від базового до високого. Ви можете вибрати формат навчання (за запитом, онлайн або офлайн) відповідно до власного розкладу. Пройшовши сертифікацію, ви перевірите й підтвердите свої навички та досвід роботи з технологіями Google Cloud.

Посібник востаннє оновлено 2 квітня 2024 року

Практичну роботу востаннє протестовано 14 серпня 2023 року

© Google LLC 2025. Усі права захищено. Назва та логотип Google є торговельними марками Google LLC. Усі інші назви компаній і продуктів можуть бути торговельними марками відповідних компаній, з якими вони пов’язані.