GitHub Actions is a powerful and flexible tool for automating software development workflows directly within your GitHub repository. One of the key features of GitHub Actions is the ability to create reusable workflows that can be easily shared and reused across multiple projects. In this post, we'll explore how to create a reusable workflow in GitHub Actions and share some resources for further reading.

Creating a Reusable Workflow
To create a reusable workflow, you'll need to create a new file in your GitHub repository at .github/workflows/ with the extension .yml. In this file, you'll define the steps in your workflow using a YAML syntax. Here's a simple example of a reusable workflow that runs a Python script on every push to the master branch:

name: Python script

on:
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: 3.8

    - name: Install dependencies
      run: |
        pip install -r requirements.txt

    - name: Run Python script
      run: |
        python script.py

To make this workflow reusable, you can store it in a separate GitHub repository and reference it in other repositories using a GitHub Actions remote workflow. The remote workflow reference will look like this:
javascript

uses: owner/repo/path to file

For example, if your reusable workflow is stored in the repository actions-workflow in the path .github/workflows/python.yml, the reference would be:

uses: actions-workflow/python.yml

References
Here are some references for further reading on GitHub Actions reusable workflows:
• GitHub Actions official documentation
• Reusing Actions in Your Workflow
• Creating a Reusable Workflow
I hope this post helps you create and reuse workflows in GitHub Actions. Happy automating!

Мантра дня
https://www.youtube.com/watch?v=8iAb9wVvFmw&ab_channel=MeditationRelaxation

🪐 Git – це величезний репозиторій корисних ресурсів для всіх, хто пов’язаний з розробкою. Не дивно, чому платформу посиленно розвивають і навіть є окремий напрям GitOps.

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

У нотатці наведено короткий допис про GitOps для Kubernetes з переліком корисних ресурсів для роботи (інструменти, секрети, туторіали й посилання на ком’юніті).

6 квітня запрошуємо на вебінар "Захищені віртуальні робочі місця за допомогою AWS Workspaces"!

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

Детально поговоримо про:

використання AWS WorkSpaces для віддаленого керування ресурсами та впровадження корпоративних політик безпеки;
аварійне відновлення та сценарії безперервності роботи бізнесу за допомогою AWS WorkSpaces;
найкращі практики використання AWS WorkSpaces для захисту даних вашої організації.

Спікер: Вадим Коваленко, Cloud Architect в Triangu
Дата й час: 6 квітня о 18:00 (GMT +3)
Місце: онлайн
Приєднуйтесь, участь безкоштовна 👉 https://bit.ly/40tB0UP

How to choose the database

RTO vs RPO

RTO (Recovery Time Objective) - це час, необхідний для відновлення роботи системи після непередбачуваної аварії чи катастрофи. Це означає, що ви маєте план дій та ресурси для того, щоб швидко відновити роботу системи після надзвичайної ситуації.

RPO (Recovery Point Objective) - це час, на який ви зможете відновити дані після аварії або катастрофи. Це означає, що ви маєте резервне копіювання даних, які можуть бути відновлені у разі втрати.

Планування RTO та RPO є ключовим елементом в будь-якій системі інформаційної безпеки. Це допомагає компанії зменшити ризики від аварій та зберегти бізнес-процеси у разі непередбачуваних ситуацій.

https://ucloud.ua/rto-i-rpo/

Трохи про import в Terrafom та GCP

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

Ось кроки для використання команди "import" в Terraform для GCP:

Визначте ресурс, який ви хочете імпортувати: Першим кроком є визначення ресурсу, який ви хочете імпортувати. Вам потрібно знати тип та назву ресурсу, а також будь-яку іншу ідентифікаційну інформацію, таку як ID або URL.

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

Запустіть команду import: Після визначення ресурсу в вашій конфігурації Terraform ви можете використовувати команду "import", щоб перенести ресурс під керування Terraform. Команда "import" приймає два аргументи: тип ресурсу та його ідентифікатор.

Припустим що вже є створена руками VM з назвой instance-1

terraform import google_compute_instance.instance-1 <project>/<zone>/instance-1

p.s. імпорт буде видно в стейті але терраформ сам за вас не напише код) тому треба буде описати ресурс в терраформ маніфестах

#sla #slo

SLA, SLO та SLI - це три скорочення, пов'язані з управлінням рівнем обслуговування в ІТ-індустрії.

SLA (Service Level Agreement) - це угода про рівень обслуговування між клієнтом і постачальником послуг, яка визначає якість та рівень обслуговування, що повинен бути забезпечений постачальником. Це документ, який фіксує мінімальний рівень якості послуг, який гарантується постачальником.

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

SLI (Service Level Indicator) - це метрика або показник, який використовується для вимірювання рівня обслуговування. Він дозволяє відслідковувати те, наскільки успішно виконується поставлене завдання в рамках угоди про рівень обслуговування.

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

Коротке відео де подробно розглянуті всі три метрикі
https://www.youtube.com/watch?v=2alcBvMBRzw&ab_channel=EfeltiLanglover

Всі відосікі з KubeCon EU 2023 https://www.youtube.com/playlist?list=PLj6h78yzYM2PyrvCoOii4rAopBswfz1p7