DevOps | Вопросы собесов

🔥Тесты для подготовки к собеседованию🔥 Выбери своё направление: 1. Frontend 2. Python 3. Java 4. Тестировщик QA 5. Data Science 6. DevOps 7. C# 8. С/C++ 9. Golang 10. PHP 11. Kotlin 12. Swift

Для чего нужен бюджет ошибок ? Спросят с вероятностью 13% Бюджет ошибок (error budget) — это концепция, используемая в области управления надёжностью систем и DevOps, которая определяет допустимый уровень риска или количество времени простоя, которое можно "потратить" без вреда для пользовательского опыта или бизнес-целей. Эта концепция особенно популярна в методологиях SRE (Site Reliability Engineering, инженерия надёжности сайтов), разработанной в Google для управления масштабируемыми и надёжными IT-инфраструктурами. Назначение: 1️⃣Установление показателей надёжности: Бюджет ошибок помогает определить, какой уровень надёжности требуется для приложения или сервиса. Например, если у сервиса цель SLA (Service Level Agreement) 99.95% доступности, это означает, что допустимое время простоя — примерно 4.38 часа в год. 2️⃣Сбалансированное управление рисками и инновациями: Бюджет ошибок позволяет командам разработки и эксплуатации сбалансировать между стабильностью сервиса и скоростью внедрения новых изменений. Если бюджет ошибок не исчерпан, команды могут рисковать больше, внедряя инновации. Если бюджет перерасходован, команды должны сосредоточиться на улучшении стабильности и надёжности. 3️⃣Повышение ответственности и прозрачности: Установление бюджета ошибок создаёт чёткие ожидания и цели для команды, способствует развитию культуры измерения и ответственности за качество и надёжность. 4️⃣Оптимизация процессов разработки и эксплуатации: Бюджет ошибок может стать отправной точкой для анализа и оптимизации процессов разработки, тестирования и управления инфраструктурой. Предположим, что у вас есть веб-сервис с SLA, установленным на уровне 99.9% доступности. Это означает, что ваш сервис может быть недоступен до 8.76 часов в год без нарушения SLA. Если в течение квартала вы уже исчерпали 2 часа вашего бюджета ошибок из-за непредвиденных сбоев, у вас остаётся 6.76 часов на оставшуюся часть года. Эта информация может повлиять на принятие решений о запуске новых функций, которые потенциально могут привести к дополнительным рискам. Бюджет ошибок — это мощный инструмент для управления рисками, качеством и скоростью инноваций в IT-проектах. Он помогает командам находить оптимальное соотношение между надёжностью и быстрым внедрением изменений, а также поддерживает культуру постоянного улучшения качества и надёжности сервисов. 👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент 🔐 База собесов | 🔐 База тестовых

Почему тебя не зовут на интервью? Исправь это в своем резюме… Получить приглашение на интервью сейчас сложнее, чем с нуля обучиться разработке. И к сожалению, это не шутка. Скорее всего только 1-2% работодателей сейчас позовут тебя на интервью. Это статистика, которую мы собирали по 10.000 откликам. Но над этой цифрой можно и нужно работать. Если правильно оформить свое резюме, и поменять свою стратегию с откликами, то конверсию можно увеличить до 10%. Т.е почти в 10 раз! Как это сделать? 1. Проверить свое резюме по нашему чек листу, и внести в него то, чего будет не хватать. 2. Поменять свой подход к поиску работы, ведь одними откликами на hh.ru сыт не будешь. 18 июня, в 18:00 по москве, мы вместе с Максом из CodeReview проведем вебинар на тему эффективного поиска работы в 2024 году. На нем Макс покажет как сейчас нужно искать работу. В прямом эфире. А также раскроет что именно нужно писать в свое резюме, чтобы оно ПРОДАВАЛО. Получить чек лист по составлению резюме, а также зарегистрироваться на вебинар можно по этой ссылке. Регистрируйся сейчас и увидимся 18 июня, в 18:00 по мск. 👉 Зарегистрироваться и получить чек-лист по резюме.

Зачем нужен multi stage ? Спросят с вероятностью 13% Многоэтапная сборка (multi-stage build) — это метод, который позволяет организовать Dockerfile более эффективно, оптимизируя размер конечного образа и уменьшая его атакуемую поверхность. Это достигается за счет использования нескольких инструкций FROM в одном Dockerfile, каждая из которых создаёт новый этап сборки. Такой подход позволяет использовать одни базовые образы для сборки и компиляции приложения, а другие — для выполнения, что существенно уменьшает размер и содержание финального образа. Преимущества: 1️⃣Оптимизация размера образа: В процессе сборки можно использовать тяжелые образы с большим количеством инструментов и зависимостей, необходимых для компиляции или тестирования приложения. Для запуска приложения используются минимальные образы, содержащие только необходимые зависимости. Это снижает размер финального образа, что ускоряет загрузку и развертывание. 2️⃣Уменьшение атакуемой поверхности: Минимизированный финальный образ содержит меньше компонентов, что уменьшает потенциальные уязвимости и упрощает поддержку безопасности. 3️⃣Эффективное кэширование и быстрота сборки: Использование многоэтапной сборки позволяет более эффективно использовать кэш Docker, поскольку изменения в одном этапе не влияют на кэш других этапов. 4️⃣Разделение зависимостей: Разработка и запуск могут требовать разных зависимостей, и многоэтапная сборка позволяет четко их разделить, снижая риски конфликтов и ошибок во время выполнения.

# Этап сборки
FROM gcc:8.3.0 as builder
WORKDIR /app
COPY . .
RUN g++ -o myapp main.cpp

# Этап запуска
FROM alpine:latest
COPY --from=builder /app/myapp /app/myapp
CMD ["/app/myapp"]

В этом примере: ✅Первый этап использует образ gcc:8.3.0 для компиляции приложения. ✅Второй этап использует минимальный образ alpine, в который копируется только исполняемый файл myapp, собранный на предыдущем этапе. Многоэтапные сборки Docker предлагают мощный способ уменьшить размер и повысить безопасность Docker-образов, упростить процессы CI/CD и улучшить управление зависимостями в приложениях. Это делает их идеальным выбором для производственных сред, где важны как производительность, так и безопасность. 👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент 🔐 База собесов | 🔐 База тестовых

Как оформить свой профиль на Github, чтобы работодатель тебя заметил? Хей! А ты знал, что 68% работодателей отбирают себе junior разработчиков основываясь на их портфолио на Github? Следовательно если ты никогда не занимался оформлением своего Github портфолио и профиля – тебе вероятнее всего пришлют отказ. Это работает именно у начинающих разработчиков. И что делать в таком случае? – На самом деле страшного ничего нет, нужно просто уделить время и оформить его по чек листу, который подготовил Макс из codereview со своей командой. Получить этот чек лист ты можешь по этой ссылке. Помимо чек листа, мы с Максом проведем вебинар 18 июня в 18:00 по мск, на тему того, как искать эффективно искать работу разработчиком в 2024 году. Чек лист будет доступен после регистрации на вебинар. 👉 Регистрируйся по этой ссылке.

Что такое репликасет, деплоймент ? Спросят с вероятностью 26% ReplicaSet и Deployment — это контроллеры, которые используются для управления жизненным циклом подов (групп контейнеров). Оба они предназначены для обеспечения отказоустойчивости и масштабируемости приложений, но они отличаются по функциональности и уровню абстракции. ReplicaSet Это контроллер, который обеспечивает, чтобы указанное количество копий пода всегда было запущено в кластере Kubernetes. Основная задача ReplicaSet — поддерживать стабильное количество реплик пода, которое определено в его конфигурации. Если поды неожиданно падают или удаляются, ReplicaSet автоматически запускает новые поды, чтобы компенсировать недостающие или избыточные экземпляры. Пример:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:1.0
В этом примере ReplicaSet гарантирует, что всегда будут запущены три пода с приложением 

myapp. Deployment Это более высокоуровневый контроллер по сравнению с ReplicaSet и предоставляет дополнительные возможности для управления развертыванием и обновлением приложений. Deployment управляет ReplicaSets и подами за вас, что позволяет легко обновлять приложения с использованием стратегий, таких как "Rolling Update" (постепенное обновление), которые минимизируют время простоя при обновлении приложения. Автоматически управляет созданием новых ReplicaSets для каждого нового обновления приложения и может откатывать к предыдущим версиям, если обновление не удаётся или отменяется. Пример:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:2.0

В этом примере Deployment управляет созданием подов с использованием образа myapp:2.0 и обеспечивает их постепенное обновление с минимальным простоем. ✅ReplicaSet предназначен для поддержания заданного числа копий пода в работе, не обеспечивая дополнительных функций для управления версиями или стратегий обновления. ✅Deployment предоставляет более комплексные функции управления, включая обновления, откаты и масштабирование приложений. Deployment использует ReplicaSets для поддержания стабильности приложений, но добавляет возможности для более гибкого управления конфигурациями и версиями. Использование Deployment рекомендуется для большинства приложений, так как оно обеспечивает больше возможностей и гибкости при управлении развертываниями. 👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент 🔐 База собесов | 🔐 База тестовых

⚡️ RECURA - полезный канал для разработчиков и инженеров. Канал ведёт DevOps-инженер, который ежедневно публикует: — код, повышающий эффективность разработки — лайфхаки и полезные трюки для Bash・Linux・macOS — советы по информационной безопасности — актуальные новости из мира технологий и нейросетей Подпишись на @recura_tech, чтобы каждый день открывать для себя что-то новое и быть востребованным специалистом.

Привет, мне нужно несколько контент-менеджеров для новых телеграм каналов в тематике программирования. Если вам интересна такая работа напиши мне @kivaiko и лучше сразу напишите какие языки программирования учите/знаете

Что лучше: микросервисы или монолиты ? Спросят с вероятностью 13% Вопрос о том, что лучше — микросервисы или монолитные архитектуры, зависит от множества факторов, включая специфику проекта, размер и навыки команды, требования к масштабируемости и доступности. Каждый подход имеет свои преимущества и недостатки, и выбор должен основываться на конкретных потребностях бизнеса и технических требованиях. Давайте рассмотрим ключевые аспекты каждого подхода. Монолитные архитектуры Преимущества: ✅Простота разработки и развертывания: Все части приложения разработаны вместе, что упрощает тестирование, отладку и развертывание, поскольку требуется управлять только одним исполняемым файлом. ✅Простота управления зависимостями: Все зависимости находятся внутри одного проекта, что уменьшает сложность управления внешними зависимостями. ✅Подходит для маленьких и средних проектов: Монолиты могут быть более эффективными для маленьких команд или проектов с ограниченными ресурсами. Недостатки: ✅Масштабируемость: Масштабирование всего приложения, даже если это необходимо только для одной части функционала, может быть ресурсоемким. ✅Гибкость разработки: Большие монолитные кодовые базы могут стать сложными для управления и медленными в разработке. ✅Трудности в обновлении технологий: Обновление или изменение технологического стека может быть сложным и рискованным для всего приложения. Микросервисные архитектуры Преимущества: ✅Масштабируемость: Микросервисы можно масштабировать независимо, что обеспечивает более эффективное использование ресурсов и улучшенное управление нагрузкой. ✅Гибкость разработки и внедрения новых технологий: Каждый микросервис может использовать наиболее подходящий для своих задач технологический стек. ✅Устойчивость к отказам: Отказ одного сервиса не обязательно влечет за собой сбой всей системы. ✅Простота обновления и поддержки: Меньший объем кода в каждом сервисе упрощает понимание, тестирование, обновление и поддержку. Недостатки: ✅Сложность управления: Микросервисные архитектуры требуют сложной инфраструктуры, включая сетевые взаимодействия, обнаружение сервисов, балансировку нагрузки и управление конфигурацией. ✅Проблемы согласованности данных: Работа с распределенными данными и транзакциями может быть сложной. ✅Высокие требования к навыкам команды: Разработка и поддержка микросервисов требуют более глубоких знаний и опыта в области сетевой инфраструктуры, безопасности и разработки распределенных систем. Выбор подхода ✅Для стартапов и небольших проектов с ограниченными ресурсами часто предпочтительнее монолит, поскольку он требует меньших затрат на начальном этапе и проще в управлении. ✅Для больших, сложных приложений, требующих высокой масштабируемости, устойчивости к отказам и быстрого внедрения изменений, микросервисы могут предложить значительные преимущества. Выбор между монолитной и микросервисной архитектурой зависит от специфических целей проекта, требований к масштабируемости, ресурсов команды и стратегических бизнес-целей. 👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент 🔐 База собесов | 🔐 База тестовых

🖥 DEVOPS — канал-гайд, который поможет тебе стать востребованным DEVOPS спецом с самого нуля. Это настоящий кладезь полезной информации, первоисточник того, что появляется в платных гайдах и курсах. • Где изучать DevOps. Лучшие бесплатные курсы, книги и полезные материалы • Это пошаговое руководство как расти и развиваться в DevOps • Самые востребованные команды Docker • 90 дней DevOps — обновлённый сборник • А здесь мы собрали папку лучших ресурсов, которые поднимут ваш уровень до небес. Подписывайтесь, такие знания на вес золота в 2024 году: @DevOPSitsec

Что такое API и зачем оно нужно ? Спросят с вероятностью 13% API (Application Programming Interface — программный интерфейс приложения) — это набор правил, спецификаций, инструментов и протоколов, который позволяет создавать ПО и приложения, обеспечивая взаимодействие между различными программными компонентами, системами и библиотеками. Ключевые функции: 1️⃣Интерфейс: API определяет, каким образом программы и компоненты могут взаимодействовать друг с другом, без необходимости вникать в детали их внутренней реализации. Это позволяет разработчикам использовать функциональность, которую предоставляет API, не заботясь о сложности внутренних процессов. 2️⃣Абстракция: API абстрагирует сложность взаимодействия с нижележащими системными уровнями или внешними сервисами, предоставляя разработчикам простой и понятный интерфейс для использования. 3️⃣Стандартизация: API устанавливает стандартные методы для выполнения различных операций, что гарантирует совместимость и унификацию взаимодействия различных компонентов программного обеспечения. Зачем он нужен? 1️⃣Интеграция систем: Позволяет различным системам и приложениям легко взаимодействовать друг с другом. Например, API веб-сервисов позволяет веб-приложениям запрашивать данные у серверов и выводить их пользователям в удобной форме. 2️⃣Расширение функциональности: С помощью сторонних API разработчики могут расширять функциональность своих приложений, используя уже готовые решения, такие как карты Google Maps, платежные системы PayPal или функции социальных сетей. 3️⃣Масштабируемость: Позволяет системам эффективно масштабироваться, предоставляя модульные компоненты, которые можно легко заменять или обновлять без влияния на другие части системы. 4️⃣Безопасность: С помощью можно контролировать доступ к различным функциям системы, обеспечивая безопасное взаимодействие между компонентами. API может служить прослойкой, которая проверяет и фильтрует запросы перед доступом к важным ресурсам. 5️⃣Разработка программного обеспечения: API упрощает разработку программ, позволяя разработчикам сосредоточиться на создании уникальных особенностей своего приложения, а не на реализации уже известных функций, доступных через API. Примеры использования: ✅Веб-API: Позволяют веб-приложениям запрашивать данные с серверов. Например, RESTful API используется для обмена данными между клиентом и сервером через HTTP. ✅Операционные системы API: Как Windows API, позволяет разработчикам писать функции, которые могут взаимодействовать с ОС. ✅Библиотеки и фреймворки: Такие как jQuery в веб-разработке, предоставляют API, которые упрощают выполнение часто используемых задач, таких как AJAX-запросы. API играет центральную роль в современной разработке ПО, делая возможной интеграцию и взаимодействие между различными программными продуктами и платформами. 👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент 🔐 База собесов | 🔐 База тестовых

⚡️В сети начали находить курсы и книги известных онлайн школ в открытом доступе Вот отсортированная база с тонной материала(постепенно пополняется): 🔗 БАЗА (3385 видео): (343 видео, 87 книги) — Java (176 видео, 32 книги) — Git (293 видео, 63 книги) — C# (352 видео, 89 книги) — С++ (167 видео, 53 книги) — PHP (227 видео, 83 книги) — SQL (163 видео, 29 книги) — Linux (363 видео, 122 книги) — Python (415 видео, 168 книги) — Frontend (143 видео, 33 книги) — Flask (167 видео, 43 книги) — Django (197 видео, 49 книги) — Разработка ботов (137 видео, 93 книги) — Data Science (113 видео, 82 книги) — GameDev (129 видео, 73 книги) — QA Скачивать ничего не нужно — все выложили в Telegram и на YouTube с доступом по ссылке

В чем разница Deployment и DaemonSet ? Спросят с вероятностью 26% Deployment и DaemonSet являются двумя типами контроллеров, которые управляют развертыванием и обеспечением жизненного цикла подов (групп контейнеров). Они оба играют важные роли, но используются для разных целей и сценариев. Deployment Это контроллер, который обеспечивает декларативное обновление подов и ReplicaSets (другой тип контроллера, который управляет одновременным запуском нескольких экземпляров одного и того же пода). Deployment поддерживает непрерывное развертывание, откат к предыдущим версиям, а также масштабирование подов. Особенности: ✅Масштабирование: Вы можете увеличивать или уменьшать количество подов в зависимости от нужд. ✅Обновления: Поддерживает стратегии развертывания, такие как Rolling Update (постепенное обновление), которое помогает минимизировать простои при обновлении приложения. ✅Самовосстановление: Автоматически перезапускает поды, которые перестали работать, находятся в ошибочном состоянии или не отвечают. Пример:

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

DaemonSet Это контроллер, который гарантирует, что на каждом узле кластера Kubernetes запущен экземпляр заданного пода. Когда добавляется новый узел, на нем автоматически запускается под, управляемый DaemonSet, и если узел удаляется, поды удаляются автоматически. Это идеально подходит для запуска служб мониторинга, сбора логов или других утилит, которые должны быть запущены на каждом узле. Особенности: ✅Гарантия запуска: Убедитесь, что каждый узел кластера запускает копию определённого пода. ✅Автоматическое размещение: Когда добавляются новые узлы, на них автоматически размещаются необходимые поды. ✅Службы уровня узла: Идеально подходит для запуска системных служб, таких как коллекторы логов, системы мониторинга и другие. Пример DaemonSet в YAML-формате:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: fluent/fluentd:v1.0
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true

Deployment и DaemonSet выполняют различные функции в Kubernetes. Deployment лучше всего подходит для управления подами, которые представляют приложения, требующие масштабирования и обновлений. DaemonSet идеален для обеспечения работы сервисов на каждом узле кластера. Оба эти инструмента дополняют друг друга и используются в разных сценариях для эффективного управления и оркестрации контейнеров. 👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент 🔐 База собесов | 🔐 База тестовых

Привет, ребят, хочу сделать так, чтобы для каждого вопроса было поясняющее видео в reels/shorts формате. Ищу человека который с этим поможет, работу оплачу. Вопросы есть, нужен простой монтаж и озвучка. Все видосы делаются по шаблону. Если интересует такая подработка напишите мне @kivaiko

Что такое blue green deployment ? Спросят с вероятностью 13% Blue-green deployment — это метод развертывания ПО, который предназначен для минимизации или устранения простоя при обновлении версии приложения. Этот подход включает в себя две идентичные среды, которые находятся в точном зеркальном отображении друг друга. Одна среда, обычно называемая "blue", активно служит трафиком пользователей, в то время как другая среда, "green", находится в готовности и используется для новой версии приложения. Как он работает 1️⃣Подготовка двух сред: Настройте две параллельные среды ("blue" и "green"). Обе должны быть настроены так, чтобы могли поддерживать полную нагрузку вашего приложения. 2️⃣Развертывание в зеленую среду: Новая версия приложения развертывается в "green" среду, где она может быть тщательно протестирована и проверена на ошибки. В это время "blue" среда по-прежнему обрабатывает весь пользовательский трафик. 3️⃣Переключение трафика: После того как новая версия в "green" среде была проверена и готова к использованию, трафик пользователей перенаправляется со "старой" синей среды на "новую" зеленую. Это переключение обычно происходит путем изменения конфигурации DNS или с помощью балансировщика нагрузки. 4️⃣Мониторинг и откат при необходимости: После переключения трафика на "green" среду, она активно мониторится для выявления любых неожиданных проблем или сбоев. Если что-то идет не так, можно быстро выполнить откат, снова переключив трафик обратно на "blue" среду. 5️⃣Подготовка следующего обновления: После успешного переключения "green" среда становится новой "blue" средой для следующего цикла развертывания, а старая "blue" среда теперь будет использоваться для следующего обновления как "green". Преимущества: ✅Минимизация простоя: Переключение между средами позволяет обновлять приложения без простоев. ✅Уменьшение риска: Тестирование новой версии в зеленой среде перед полноценным переключением трафика помогает убедиться в стабильности обновления. ✅Быстрый откат: Если новая версия содержит ошибки, можно быстро переключиться обратно на старую версию. Недостатки: ✅Двойные затраты на инфраструктуру: Требуется поддерживать две рабочие среды, что удваивает затраты на ресурсы и управление. ✅Сложность управления данными: Синхронизация данных между двумя средами может быть сложной, особенно если приложение вносит значительные изменения в данные. Blue-green deployment является эффективным способом обеспечения надежности и непрерывности бизнес-процессов при обновлении приложений, особенно в условиях критически важных продуктовых сред. 👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент 🔐 База собесов | 🔐 База тестовых

🔥 Подъехали ништяки для тех, кто настраивает окружение и автоматизирует процессы 💪😎 Cloud․ru предлагает бесплатный доступ к облачным ресурсам через Free Tier. Это отличная возможность развернуть приложения совершенно бесплатно. ⚔️ Вы получаете доступ к виртуальной машине с конфигурацией 2vCPU и 4 ГБ RAM, а также 30 ГБ на SSD, что вполне достаточно для тестирования и разработки приложений. Также предоставляется 5 ГБ хранилища S3 с тысячами операций загрузки и извлечения данных. ➡️ Для выхода ВМ в интернет оплатите публичный IP за 146 (🍟) рублей или воспользуйтесь бонусом в 4000 рублей для новых клиентов при привязке карты или регистрации по Сбер ID. 🍀 Ловите удачу, просто перейдя по этой ссылке.

Какие есть способы задания переменных в Ansible ? Спросят с вероятностью 13% Переменные используются для хранения информации, которая может изменяться от одного выполнения плейбука к другому или от одного окружения к другому. Это делает Ansible более гибким и повторно используемым. Существует несколько способов определения и использования переменных в Ansible: 1️⃣Переменные в инвентарных файлах Можно задать непосредственно в инвентарном файле. Это могут быть файлы в форматах INI или YAML. Пример в формате INI:

[webservers]
webserver1 ansible_host=192.168.1.100 http_port=80 max_requests=1000

В YAML формате это будет выглядеть так:

webservers:
  hosts:
    webserver1:
      ansible_host: 192.168.1.100
      http_port: 80
      max_requests: 1000

2️⃣Файлы переменных в плейбуках Могут быть организованы в файлы, обычно YAML, которые затем подключаются к плейбукам через директиву vars_files. Пример использования в плейбуке:

---
- hosts: all
  vars_files:
    - vars/main.yml

Где vars/main.yml содержит:

http_port: 80
max_requests: 1000

3️⃣Переменные в командной строке Могут быть определены непосредственно при запуске плейбука через командную строку с помощью ключа -e или --extra-vars. Пример:

ansible-playbook playbook.yml -e "http_port=80 max_requests=1000"

4️⃣Переменные в плейбуках Можно определить непосредственно в плейбуке под ключом vars:

---
- hosts: all
  vars:
    http_port: 80
    max_requests: 1000

5️⃣Role Defaults и Vars Каждая роль может иметь файлы defaults/main.yml и vars/main.yml. Переменные, определенные в defaults, имеют самый низкий приоритет и могут быть переопределены почти в любом месте. Переменные в vars имеют более высокий приоритет и переопределяются с трудом. 6️⃣Registered Variables Переменные могут быть созданы во время выполнения плейбука с использованием модулей и зарегистрированы для использования в последующих задачах. Например:

- name: Get the date
  command: date
  register: current_date

7️⃣Facts Собираются Ansible автоматически при выполнении плейбука и содержат информацию о удалённых системах. Facts можно использовать как переменные:

---
- hosts: all
  tasks:
    - name: Print OS family
      debug:
        msg: "The OS family is {{ ansible_os_family }}"

Каждый из этих способов имеет своё применение в зависимости от требований задачи, структуры данных и логики плейбука. Правильный выбор способа определения переменных помогает создать более читаемые, поддерживаемые и масштабируемые Ansible плейбуки и роли. 👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент 🔐 База собесов | 🔐 База тестовых

ИТ-сообщество с 14-летним стажем ⌨️ ITKB_channel — бесплатное обучение по Windows, Linux, DevOps, Security, Network, программирование 📚 ITKB_Archive — библиотека (книги, курсы, ИТ литература)

Что известно про rancher kubernetes ? Спросят с вероятностью 13% Rancher — это популярная платформа управления контейнерами, которая позволяет упростить процесс развертывания, управления и масштабирования приложений на основе контейнеров, включая тех, что работают в среде Kubernetes. Rancher обеспечивает интеграцию с различными инструментами и платформами, такими как Docker, Kubernetes, Microsoft Azure, Google Cloud Platform и Amazon Web Services. Основные возможности и преимущества: 1️⃣Поддержка множества кластеров Kubernetes: Позволяет управлять несколькими кластерами Kubernetes, независимо от того, где они развернуты — будь то на ваших локальных серверах или в облаке. 2️⃣Удобный пользовательский интерфейс: Предоставляет графический интерфейс пользователя (GUI), который упрощает управление ресурсами Kubernetes, мониторингом, масштабированием и обновлениями. 3️⃣Интегрированная система безопасности: Включает средства для управления доступом, которые позволяют настроить политики безопасности на уровне пользователей и групп, а также интегрируется с внешними поставщиками идентификации через OpenID Connect, LDAP, Active Directory и другие. 4️⃣Управление каталогами приложений: Предоставляет каталоги, которые содержат готовые шаблоны приложений, упрощая развертывание стандартных сервисов и приложений. 5️⃣Проекты и пространства имен: Позволяет группировать ресурсы Kubernetes в проекты, что упрощает управление и изоляцию ресурсов между командами или приложениями. 6️⃣Масштабирование и автоматизация: Упрощает процесс масштабирования приложений и автоматизации операций с помощью различных инструментов и API. Использование для управления Kubernetes Предоставляет дополнительный слой абстракции и управления над кластерами Kubernetes, который включает: ✅Централизованное управление: Управляйте всеми вашими кластерами Kubernetes из единого интерфейса. ✅Автоматическое развертывание: Простое создание новых кластеров Kubernetes на различных облачных платформах или на локальных серверах. ✅Мониторинг и алерты: Встроенные средства для мониторинга состояния кластера и оповещения о проблемах. ✅Бэкап и восстановление: Инструменты для резервного копирования и восстановления состояния кластера. Rancher является мощным инструментом для организаций, которые используют Kubernetes и стремятся упростить управление своей инфраструктурой контейнеров. Он обеспечивает дополнительные уровни управления, безопасности и масштабируемости, что делает его ценным решением для развертывания и управления контейнеризированными приложениями в различных средах. 👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1119 вопросов на DevOps. Ставь 👍 если нравится контент 🔐 База собесов | 🔐 База тестовых

🚀 Приглашаем на звонок для начинающих DevOps'ов! 📅 Когда: 15го июня в 10.00 МСК 📍 Где: Онлайн, ссылка для подключения будет в группе DevOps фабрики https://t.me/devops_factory Ты узнаешь: 🔹 Что учить, чтобы стать DevOps специалистом 🔹 Какой начальный уровень нужен На звонке от DevOps фабрики рассмотрим: Хард скиллы: какие технические знания и навыки необходимы Софт скиллы: как развивать коммуникативные и управленческие умения Обсудим, как потренироваться с нужными технологиями и куда расти, чтобы достичь успеха в этой сфере. 🎤 Задай свой вопрос: Что предпринять в твоем конкретном случае? Мы поможем разобраться! Ссылку опубликую в канале : https://t.me/devops_factory Не упусти шанс начать свой путь в DevOps с правильного старта!