Перестал запускаться minikube
Доброго дня! Может кто уже сталкивался и как то решил. Зависает запуск minikube
Docker на практике
Книга "Docker на практике" Иана Милла, Эйдана Хобсона и Сейерса - это практическое руководство, которое позволяет читателям изучить и использовать технологию контейнеризации Docker. Благодаря подробным объяснениям, примерам кода и наглядным иллюстрациям, авторы позволяют читателям получить полное представление о том, как использовать Docker для разработки, тестирования и развертывания приложений.
Аннотация представляет собой полезное описание содержания книги, в котором указываются основные темы, концепции и примеры, рассмотренные в книге.
Книга начинается с введения в Docker, где объясняются основные понятия и преимущества контейнеризации. Затем авторы рассматривают основные этапы работы с Docker, включая установку и конфигурацию, создание Docker-образов и контейнеров, а также управление развертыванием и масштабированием приложений.
В следующих главах книги подробно описываются различные аспекты использования Docker в разработке и тестировании приложений. Для этого рассматриваются такие темы, как создание и использование сред для разработки, использование инструментов для автоматизации тестирования и развертывания, а также интеграция Docker с другими технологиями разработки.
Особое внимание уделено безопасности и мониторингу в контексте Docker. Авторы рассматривают различные сценарии защиты Docker-контейнеров и предлагают рекомендации по работе с проблемами безопасности. Они также представляют инструменты и методы для мониторинга и отладки приложений на Docker.
Книга "Docker на практике" также включает в себя примеры реальных проектов, где авторы демонстрируют, как применять Docker в различных сценариях. Эти примеры помогают читателям лучше понять, как использовать Docker в реальной жизни.
В целом, "Docker на практике" является полезным руководством для разработчиков и системных администраторов, которые хотят освоить Docker и использовать его для разработки и развертывания приложений. Авторы предоставляют читателям практические инструменты и советы, которые позволяют быстро и эффективно начать работу с Docker.
Книгу можно скачать в ТГ канале https://t.me/bitebusters/39
ГОТОВИМ DOCKERFILE ДОМА
Привет! Прошлый ролик по докеру не зашёл, а залетел просто! Комментарии просто взорвались, как и моя пятая точка от некоторых из них)))
И я решил снять продолжение! Надеюсь вам понравится!
DOCKER БЫТОВОЙ УРОВЕНЬ
Привет! Это небольшой гайд для новичков в Docker, который должен помочь тебе начать пользоваться докером!
Как создавать софт, как SRE
Перевод очень интересной статьи "How to Build Software like an SRE", в которой разбираются подходы к созданию приложений с точки зрения SRE.
Принципы надежности и компромиссы, усвоенные на собственном горьком опыте
Я занимаюсь этой “надежностью” уже некоторое время (около 5 лет), в компаниях, насчитывающих от 20 до более чем 2000 человек. Меня всегда в первую очередь всегда интересовали те элементы ПО, которые я описываю как живущие “вне” приложения — например, как приложение получает свою конфигурацию? На каких типах серверов оно запускается и являются ли эти типы наиболее подходящими? Что с ним происходит на пути от “кода в репозитории” до “запуска на проде”? И я всегда следил за тем, что мне нравится — какие механизмы позволяют быструю итерацию, а какие вызывают разочарование, какие приводят к сбоям, а какие предотвращают их.
Я думаю, что будет полезно, если я все это запишу, даже если это будет просто для меня в качестве справочника.
Обратите внимание, что этот список немного странный с точки зрения SRE. Моя цель не заключается в том, чтобы “построить все так, чтобы надежность была 100%”; это больше похоже на “как достичь 80% надежности, затратив 20% усилий, при этом позволяя разработчикам работать быстро”, что в конечном итоге дает нам систему, которая выглядит совсем по-другому. Но это стоит попробовать — если делать это хорошо, работа с продом становится интересной, а не уныло безопасной или ужасающе опасной.
Также, пожалуйста, сделайте мне одолжение и мысленно дополните каждый из следующих пунктов словом “обычно”. Каждая ситуация уникальна, и то, что я не сталкивался с тем, что (например) использование Git является плохой идеей, не означает, что такого случая не существует. “Только Ситхи всё возводят в абсолют”, и т.д.
Итак! Пройдя через всё это — вот как я бы начал все сначала, если бы мог.
Coding (параметры? да я их еле знаю!)
Никаких конфигов, зашитых в код. Если ваш сервис по какой-либо причине не может загрузить конфигурацию при запуске, он должен просто аварийно завершиться — этот случай гораздо проще диагностировать, чем результат того, что инстанс выполнил старый код, потому что никто не вспомнил о том, что нужно удалить строку config.get(enable_cool_new_thing, false).
Чрезвычайно строгие настройки RPC. Я говорю о нуле (или МОЖЕТ БЫТЬ одной) повторных попыток и таймауте, в 3 раза превышающем p⁹⁹. Здесь мы стремимся к предсказуемости, и многократные повторные попытки или длительные таймауты в качестве быстрого решения проблемы в работе сервиса превратятся в недельное расследование и головную боль через год. Исправьте неисправный сервис!
Никогда не отказывайтесь от локального тестирования. Это значительно сокращает время цикла разработки, чем необходимость полагаться (и возиться с этим) на CI или удаленные рабочие среды. Контейнеризация локальной тестовой среды может упростить управление зависимостями и обеспечить их переносимость между машинами.
Избегайте использования состояния как чумы. Управление сервисом с сохранением состояния (stateful) значительно сложнее, чем без сохранения состояния. Существует много хороших управляемых баз данных и кэшей, просто используйте один из них!
Merging (там, куда мы идем — тесты не нужны)
Используйте Git. Используйте его для всего — инфраструктуры, конфигов, кода, дашбордов, графиков дежурств. Ваш репозиторий Git — это источник истины, который можно восстановить на определенный момент времени.
Не тратьте время на полное покрытие кода тестами. И вообще, не занимайтесь “расстановкой галочек” — это только для красивых графиков и диаграмм, которые имеют очень мало общего с тем, какую фактическую ценность дает ваше изменение (см. ниже).
Уделяйте приоритетное внимание тестам в реальных условиях. Самый ценный тест, который занимает меньше всего времени, — это просто применение вашего изменения на стейджинге (или, еще лучше, на проде!) и демонстрация того, что оно делает то, что вы хотели, и не ломает всё. На втором месте по эффективности находятся интеграционные тесты, а юнит-тесты идут последними — то есть, “только если у вас есть на них время”.
При изменениях в инфраструктуре делайте планы максимально ясными и очевидными. Это может означать “положить Terraform Plan как коммент к пуллреквесту”, так же сделайте с diff helm. Существуют отличные инструменты, позволяющие убедиться, что изменения, которые, по вашему мнению, вы вносите, являются теми изменениями, которые вы вносите на самом деле, поэтому убедитесь, что они находятся в центре внимания.
При внесении изменений в код делайте регрессии максимально очевидными. Журналы ошибок, использование ЦП и частота ошибочных запросов являются отличными сигналами, позволяющими выявить около 90% плохих версий и работают для практически любого сервиса (полностью универсальны). Так что не отбрасывайте их!
Deploying (no sleep til prod)
Используйте Docker. Это отраслевой стандарт не просто так — разбор зависимостей в средах с такими инструментами, как Chef или Ansible, всегда проигрывает этой приятной автономности.
Развертывайте всё и всегда. Каждый день, который проходит без вашего деплоя, увеличивает вероятность того, что он на самом деле был незаметно сломан (в результате чьего-то изменения, обновления зависимостей, удаления стороннего API), и через две недели будет очень трудно выяснить, что и где пошло не так.
Проверяйте развертывания по мере их выполнения. Можете ли вы создать полностью поврежденный образ и успешно разлить его на все машины? Почему? Это можно исправить несколькими способами, включая canary/shadow развертывания или даже просто хорошими readiness проверками.
Включите ограничение на “мгновенное” развертывание конфигов. Это может показаться нелогичным (“мгновенное” часто означает “сломать все сразу и быстро”), но возможность отключить проблемную функцию или заблокировать IP менее чем за 5 минут с лихвой компенсирует повышенный риск. Это позволяет всё делать быстро, но управлять этим нужно осторожно!
Operating (my god, it’s full of pods)
Используйте Kubernetes. Предполагая, что у вас есть более одного сервиса и более одного инстанса, вам либо нужны, либо будут нужны такие вещи, как обнаружение сервисов, автоматическое масштабирование и управление версиями развертывания, и вы не хотите управлять всем этим самостоятельно. Kubernetes дает командам инфраструктуры сверхспособности масштабирования.
Используйте Helm. Или какой-то другой инструмент для управления манифестами Kubernetes, я не привередлив — главное, чтобы вы никогда не использовали прямые команды kubectl apply, edit или delete. Жизненный цикл ресурсов должен быть доступен в системе контроля версий.
Избегайте операторов и CRD (Custom Resource Definition). Как уже упоминалось выше, я люблю Kubernetes, но для очень многих разработчиков он очень сложен, и пользовательские операторы резко уходят в область “Что это за херня?”, что создает ему сложную репутацию. Пусть все будет просто.
Запускайте по 3 экземпляра всего. Как и с резервными копиями, два экземпляра — это один, а один — не существует :) Кроме того, убедитесь (действительно проверьте на проде), что 2 из 3 “штук” могут справиться с полной нагрузкой самостоятельно — в противном случае у вас на самом деле нет такой устойчивости к сбоям, как вы думаете.
Структурированные логи — это неотъемлемая часть. Вместе с идентификаторами трассировки они позволяют вам пройти 90% пути к APM (application performance monitoring), но при гораздо меньших затратах и усилиях со стороны разработчиков.
Итак, это текущий список! Думаю, что буду периодически возвращаться сюда и добавлять что-то еще. Пожалуйста, не стесняйтесь обращаться ко мне, если что-то из этого особенно вас раздражает или если у вас есть ещё что-то, о чем бы вы хотели бы поговорить 😜
Легко связать контейнеры Docker в одну сеть
Очень легко и удобно оказалось в Докере (compose) связывать сети. Раньше сервисы обычно пихал в один compose-файл (или, точнее, лень было разделять специально – как шли “из коробки” – так и запускались).
Но стало неудобно. Совсем неудобно стало, что каждый норовит себе отдельную БД поднять соседним контейнером. И всё равно приходится лезть, и монтирование данных для БД на хостовой ФС прописывать. Ближе к делу:
Первый сервис (у меня – БД), в docker-compose:
Сеть с драйвером bridge по умолчанию создается, но пусть явно будет прописано.
Второй сервис (автоматизация huginn):
И всё. Оба сервиса живут внутри сети postgres_net, друг-друга видят по названиям, по ним же и пингуются. huginn использует pglocal в своём конфиге.
Минус вижу – порядок ожидания нужных служб сделать посложней, чем с depends_on и службами в одном файле.
Или через docker-compose -f service1.yml -f service2.yml up все нужные службы пускать (тогда depends_on сработает). Мне не удобно так.
Или через command и внешние скрипты ожидания приходится. Хорошо, что wait-for-it.sh уже придуман до нас!
Продолжение "Простейший способ ускорить изучение мира программирования. Арендуем копеечный сервер..."
В прошлой статье я рассказал о таком понятии как VPS (Virtual Private Station).
Проще говоря, это виртуальный компьютер внутри обычного сервера (Dedicated Server). Настроим инфраструктуру, необходимую для создания промышленных приложений. Познакомимся с тем как работать с linux серверами.
Не буду рекомендовать какой то конкретный курс. Можно зайти на ютуб и вбить "Linux для начинающих" или найти книги просто загуглив "линукс начинающим pdf".
Для начала работы с линуксом нужно знать:
В какой папке вы находитесь и как сменить папку (pwd, cd)
Как создавать папки, файлы и как их читать и писать в них, как искать нужные файлы (mkdir, touch, vim, find)
Понимать самые основы прав и пользователей, как их создавать и пользоваться ими (chown, chmod, id, su)
Как устанавливать и запускать приложения (apt-get update/install/remove)
Как писать простейшие скрипты и запускать (bash scripts)
Уметь проверять состояние сервера - загрузка CPU/RAM/HDD (top, free, df)
Уметь проверять процессы и останавливать их (ps, kill)
Уметь проверить, закрыть порт (netstat и еще парочка)
К этому списку можно обавить пару команд но для начала работы этого будет достаточно. На изучение базовых операций может уйти месяц - другой, в зависимости от предыдущего опыта.
Устанавливаем на сервер необходимую для разработки инфраструктуру.
Раньше большинство инфраструктуры ставили прямо на сам сервер.
Сейчас используют разные решения виртуализации и её оркестрации, например: Docker, Kubernetes и множество других (но часть инфраструктуры продолжают ставить прямо на сервер).
Виртуализация, вроде Docker, значительно уменьшает головную боль для установки сотен решений от баз данных и очередей до чего то более сложного, вроде игровых серверов. Поэтому перед началом разработки я настоятельно рекомендую познакомиться с докером
Минимум, который нужно знать про Docker:
Понимать разницу между образом и контейнером (контейнер по сути экземпляр образа)
Уметь запускать и останавливать контейнер (docker run, stop, start)
Уметь подключаться к контейнеру (docker attach / docker exec)
Уметь проверять работу контейнера (docker ps, docker logs)
Для чего это нужно?
Изучение основ Linux и Docker - процесс не из самых легких. Все это стоит того, чтобы научиться поднимать инфраструктуру в несколько минут.
Ниже я приведу примеры классических контейнеров, которые пригодятся при изучении промышленной разработки.
Классический минимум
Рассмотрим пример архитектуры классического промышленного Java приложения:
Подобная инфраструктура вряд ли вместится в самую дешевую VPSку. Ниже я расскажу какие есть недорогие варианты.
Этот вариант архитектуры является классическим решением большинства веб проектов. Я привел его в качестве примера, который подойдет для новичка.
Используем докер для поднятия данной архитектуры.
Redis (один из многих вариантов кэшей)
Кэш позволяет временно хранить наиболее используемые данные, тем самым снижая нагрузку на систему в целом и повышая производительность.
Для простейшего варианта авторизации по паролю достаточно запустить команду:
docker run -d -p 6379:6379 --name myredis redis redis-server --requirepass <password>
Для удобства (необязательно) можно внутри докера стартовать веб интерфейс для просмотра redis сервера вот такой командой:
docker run -d --name myrediscommander -p 8081:8081 --link myredis:redis rediscommander/redis-commander
После старта админки можно зайти в браузер по адресу ВАШ_IP:8081 и затем подключиться к вашему серверу, чтобы просматривать/удалять/добавлять данные:
RabbitMQ (Очередь, которая получает сообщения и оповещает подписчиков).
Rabbit позволяет получать и оповещать клиентов, подписавшихся на сообщения.
Для запуска очереди достаточно запустить:
docker run -d --name my-rabbitmq -p 5672:5672 -p 15672:15672 -e RABBITMQ_DEFAULT_USER=myuser -e RABBITMQ_DEFAULT_PASS=mypassword rabbitmq:3-management
Через пару минут можете зайти в админку очереди, вбив в браузере IP_вашего_сервера:15672 и увидеть что то вроде:
Реляционная база данных MYSQL.
Реляционные базы данных являются неотъемлемой частью большинства решений. В нашем примере мы запустим одну из самых популярных MySQL:
docker run -d --name mysql-container -e MYSQL_ROOT_PASSWORD=password -p 3306:3306 mysql:latest --default-authentication-plugin=mysql_native_password
Через пару минут сервер стартанет. К нему можно будет подключиться через какой - нибудь MySQL клиент, например Heidi SQL.
С помощью клиента можно легко писать запросы и проверять содержание базы данных. Выглядеть он может примерно так:
Минимальные требования к подобной инфраструктуре.
Если вы хотите пользоваться докером в арендованном сервере вам желательно иметь 2 процессора и 2 Гб оперативки. Система запустится, но будет работать на минималках. Этого достаточно, чтобы изучить данные технологии.
Какие есть недорогие варианты поднятия инфраструктуры без больших затрат?
Запуск на локальной машине с тунелированием данных. В таком случае все запросы на VPS будут перенаправлены на домашний компьютер. В следующих статьях я покажу как это сделать.
Почасовая аренда VPS. Если вы хотите проверить какие - нибудь решения и вы знаете, что это займет несколько часов, есть смысл аренды VPS с почасовой оплатой. В среднем 8 ядерный VPS с 8gb RAM будет стоить порядка 5-12 рублей в час. Конкретного провайдера рекламировать не буду, я пользовался тремя и в такой диапазон цен укладывался.
Использование облаков. Данный метод я не рекомендую, за исключением тех решений, которые не тарифицируют трафик или что нибудь еще. С облаками вроде AWS можно влететь на большие деньги и новичкам я советую избегать их в начале пути.
Как еще можно использовать арендованный сервер?
Кроме разработки, сервер может подарить вам ряд бесплатных, либо условно бесплатных сервисов, которые могут вам пригодиться для работы или игр. Приведу пару примеров.
Запускаем чат сервер MatterMost
Допустим, вам надо создать чат - платформу для группы в университете или на работе с каналами, обменом приватными сообщениями с тектом и картинками. Вместо платных платформ можно запустить MatterMost сервер. К нему можно будет подключиться с компьютера или мобилки. Все это можно скачать и установить бесплатно.
Запустить сервер можно командой ниже:
docker run --name matt -d --publish 8065:8065 --add-host dockeermost/mattermost-preview
После нескольких минут к серверу можно подключиться, вот как выглядит клиент чата:
Хостим MineCraft
Для старта сервера MineCraft понадобится:
Cкачать или скопировать вручную вот такой docker-compose.yml файл: https://pastebin.com/raw/uEP58DRB сделать это можно командой
curl -o docker-compose.yml https://pastebin.com/raw/uEP58DRB
Затем, находясь в той же директории, надо запустить
docker compose up
После старта сервера нужно подождать какое то время. Затем, можно подключиться к миру, используя Minicraft клиент, указав IP вашего сервера:
Вот как выглядел мир в моем примере:
Я перечислил часть возможных решений в качестве примера.
Приведенные команды далеки от идеала и желательно их подправить, например, улучшить безопасность. Для целей ознакомления, думаю, пойдет.
Сама разработка на Java.
В следующей части я покажу как писать простейшие приложения и использовать созданную инфраструктуру.
Больше о Java и смежных технологиях можете узнать тут.