Хмарний вітрильник

#memes ☠️☠️☠️ ☁️Хмарний вітрильник☁️

#memes А у вас викачують щось на прод у п'ятницю???

#memes А як ви родичам пояснюєте ким ви працюєте?) ☁️Хмарний вітрильник☁️

Цікаві трюки з S3 Сьогодні вирішили навести кілька цікавих інструментів з використання AWS S3 бакетів, можливо ви щось з цього вже знаєте, а можливо щось навіть вам пригодиться)) Монтування S3 бакету на он преми через s3fs — дуже корисна штука коли ви не хочете орендувати новий диск, а даних у вас дуже багато, єдиний мінус — швидкодія, бо навіть швидкість підвантаження змісту директорій через ls іноді буває досить великим (в мене було до 10 секунд). Використання S3 бакетів з boto3 — корисний модуль для підключення бакетів всередині пайтон скриптів, також активно може використовуватись у комбінації з лямбда функціями (про них поговоримо окремо) Відображення дерева директорій через консольку юзаючи stree — через цю команду можна подивитись повне дерево с3 бакетів, така собі цікава утилітка для аналізу складних з точки зору структури бакетів S3 browser — по суті простенький клієнт на локальній машині, в якому як у провіднику вінди показано вміст бакетів. Між іншим аналогічна функція доступна і MobaXterm S3 event notifications — по суті своїй такі собі вебхуки с3, тобто коли у бакеті відбувається якась дія, S3 бакет може відправляти JSON повідомлення. Через це можна реалізувати тригер для запуску Lambda функції А які ви ще знаєте цікаві фічі з S3? Пишіть у коментарі😊 ☁️Хмарний вітрильник☁️

#memes Ой.... ☁️Хмарний вітрильник☁️

#info Ми бачимо на просторах інтернету багато курсів на різноманітних платформах по девопсу, але водночас бачимо, що не завжди вони приносять потрібний результат. Враховуючи досить складне економічне становище в Україні, наша команда хотіла б допомогти українцям з пошуком роботи. Настільки, наскільки це можливо з нашої сторони. Саме тому ми відкриваємо менторську програму для девопсу на нашому каналі. Це не курс в прямому розумінні цього слова, бо наша мета — щоб людина могла отримати роботу девопсом (рівня джуна-мідла), і вона могла самостійно розвиватись та вирішувати реальні задачі (тобто щоб за неї не було соромно сіньйорам які будуть з ними працювати🤣). Формат навчання — практичні завдання з онлайн підтримкою у телеграмі + зідзвони кожного тижня Стек технологій — AWS, Terraform, Gitlab CI, Linux, Docker, Kubernetes, Helm, Argo CD, Grafana, Prometheus + інші технології Підтримка під час пошуку роботи — оформлення профілю в LinkedIn, Djinni, допомога при складанні резюме, аналіз поточних вакансій, підготовка до співбесід Подробиці питайте тут👉@eugene_koshmanov

#memes ☁️Хмарний вітрильник☁️

#memes :) ☁️Хмарний вітрильник☁️

#containerization #k8s 👩‍💻 Що таке сервіси в Kubernetes? ClusterIP Ще один дуже корисний об'єкт у кубері це сервіси. Взагалі кажучи, нащо вони потрібні?😁 У кожного поду є своя IP адреса в кластері, однак вона має неприємну звучку змінюватись😬, якщо под впав. І от уяви собі, є бекенд і фронтенд мікросервіси, і їм треба якось комунікувати між собою, а у подів завжди змінюється адреса😬😬! А ще ми б хотіли щоб у нас було кілька реплік одного мікросервісу, а отже, треба якесь балансування запитів між цими подами😬😬😬... Біда одним словом. Власне, для цього і треба сервіси — це по суті об'єкти кубернетесу, які прикривають поди, такі собі "мережеві інтерфейси", через які проходить трафік до подів. Видів сервісів багато (аж цілих п'ять!), але почнімо з ClusterIP ClusterIP — це банально статична адреса для подів (деплойменту). Вона не змінюється при падінні подів, може балансувати за схемою round robin (тобто по колу) і ще має власне доменне ім'я всередині кластеру (а про це вже окремо почитайте, бо буде для вас квіз☺️( Для прикладу, ось так виглядає простенька реалізації ClusterIP:

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: my-backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: ClusterIP

Тут як бачите є своєрідний порт мепінг: параметр port — це порт ClusterIP, target port — це порт поду. Висновки? ClusterIP ідеально підходить для сценаріїв, коли вам потрібно забезпечити взаємодію між компонентами вашого застосунку всередині кластера Kubernetes. Це основний спосіб для внутрішнього взаємозв'язку між службами, коли не потрібен доступ ззовні. ☁️Хмарний вітрильник☁️

#memes Без коментарів)) ☁️Хмарний вітрильник☁️

Коли починаєш вчитись на девопса, заходиш на джині чи доу і бачиш у вакансіях стек технологій розміром з вавилонську вежу☹️ Звичайно, що здається, що такий стек технологій не осилиш навіть за рік, тому ми для наших підписників вирішили зробити невеличкий подарунок: стартові завдання по девопсу🤑 Що це таке? Гітхаб репозиторій, де є практичні задачі по амазону, тераформу, докеру та баш скриптингу. На наш погляд, завдяки цим задачам можна самостійно почати свій рух у девопсі😎 Як отримати? Просто бути підписаним на наш канал! А далі перейдіть за 👉посиланням👈 і вам там наш бот видасть завдання. Далі клонуєте собі в локальний репозиторій і працюєте!) Що далі? Вирішені задачі можете використати як база для майбутнього портфоліо, а також це дасть вам додатковий буст при проходженні нашої менторської програми ☁️Хмарний вітрильник☁️

#memes А у вас кста були випадки коли ви стріляли з гармати по горобцям? х)) ☁️Хмарний вітрильник☁️

#Linux 🔗 Софт та Хард Лінки в Linux Уявіть собі, що ви маєте один он-прем сервер. Так склалось, що у вас є кілька дисків на ньому, а на основний (де висить вся система), було поставлено докер. В якийсь момент ви помічаєте, що докер імеджі та інші ресурси докеру займають забагцько пам'яті, у той час як ваші диски простоюють. Було б дуже непогано, якби докер міг посилатись на файли імеджів у іншому диску... Як ярлик... А! В нас же є софт та хард лінки для цього, давайте з ними розберемося) 🤯Що це таке оті ваші лінки? Хард лінки створюють додаткове ім'я для існуючого файла в тій же файловій системі, дозволяючи доступ до файлу через декілька імен. Фактично, це означає, що один і той же файл може мати кілька вказівників у файловій системі. Якщо видалити оригінальне ім'я файла, хард лінк залишиться доступним, оскільки дані зберігаються на диску, доки існує хоча б один вказівник. Софт лінки (символьні лінки), з іншого боку, є посиланням на шлях файла або каталогу. Вони діють як ярлик, тому якщо оригінальний файл буде переміщено або видалено, софт лінк перестане працювати. Софт лінки можуть вказувати на файли та каталоги у різних файлових системах. 🤔Де їх можна використовувати? Хард лінки використовуються для збереження дискового простору, забезпечуючи кілька посилань на одні і ті ж дані в файловій системі, що підвищує надійність зберігання і спрощує організацію файлів без дублювання. Софт лінки, навпаки, створюють гнучкі ярлики для доступу до файлів або каталогів у різних місцях, ідеально підходять для управління версіями програм і спрощення роботи з бібліотеками, дозволяючи швидко змінювати конфігурації. 📕Домашнє завдання для новачків: для наведеного прикладу, що доцільніше використати: софт лінки чи хард лінки? (Про міграцію даних докеру з одного диску на інший ми поговоримо у наступних постах) ☁️Хмарний вітрильник☁️

#memes Жиза, особливо для MLOps-ів, коли дата сайнтисти хочуть імедж для юпайтеру де є буквально все (а потім резолвиш конфлікти версій☠️)

#containerization #k8s 👩‍💻 Що таке деплоймент в Kubernetes? Минулого разу ми розповіли що таке поди, і там в цілому все дуже просто. Наступним етапом кращої оркестрації контейнерів є деплоймент. Деплоймент - це об'єкт в Kubernetes, який дозволяє користувачам описати очікуваний стан застосунку. Він керує створенням, оновленням і видаленням подів, забезпечуючи безперервне розгортання та оновлення застосунку. Основні переваги використання деплойментів: Автоматичне управління реплікацією: ви можете вказати необхідну кількість копій вашого застосунку, і Kubernetes подбає про їх створення та утримання. Оновлення з мінімальними збоями: під час оновлення версії застосунку деплоймент забезпечує розумне управління оновленнями, дозволяючи rolling update без даунтайму. Відкат змін: якщо нова версія застосунку викликає проблеми, Kubernetes дозволяє легко відкотити до попередньої стабільної версії. Створення деплойменту включає опис конфігурації у як правило у YAML форматі, наприклад:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Тобто в результаті отримаємо три контрольованих копії одного контейнера. Якщо один контейнер впаде — деплоймент його замінить на інший, а якщо треба буде робити оновлення докер імеджу, він почергово оновить всі поди за стратегією Rolling Update. Насправді для деплойменту можна приписати дуже багато різних налаштувань, тому радимо почитати документацію кубера на цю тему 📕Домашнє завдання для новачків: яка саме частина YAML маніфесту, вказаного вище, відповідає за сам контейнер(под)? ☁️Хмарний вітрильник☁️

#memes А що ви думаєте про сертифікати? Чи дійсно вони варті самих себе? ☁️Хмарний вітрильник☁️

#memes :)