Пользователь
Важная характеристика Docker-контейнеров — эфемерность. В любой момент контейнер может рестартовать: завершиться и вновь запуститься из образа. При этом все накопленные в нём данные будут потеряны. Но как в таком случае запускать в Docker приложения, которые должны сохранять информацию о своём состоянии? Для этого есть несколько инструментов.
В этой статье рассмотрим docker volumes, bind mount и tmpfs, дадим советы по их использованию, проведём небольшую практику.
В этой части мы перестаём говорить о простом и приятном и начинаем говорить о трудном. Переменные в Ansible: scope, precedence, рекурсивная интерполяция. Для тех, кто дочитает до конца, маленький бонус: упрощённая таблица приоритетов, с которой можно жить. Предыдущие части: 1, 2.
Обычно рассказ про переменные в Ансибл начинают с чего-то очень простенького, что создаёт у читателя иллюзию, что переменные в Ансибл — это как в любом другом языке программирования. Мутабельные или немутабельные, локальные и глобальные. Это не так.
Это не так.
У Ансибла возникла уникальная модель переменных (модель памяти?), которую надо учить с нуля. И рассматривать мы её начнём с того места, где значения используются (обычно переменные Ансибла рассматривают с того места, откуда они появляются). Почему? Потому что при рассказе в этом направлении у нас образуется направленный граф, который куда легче уложить в голову.
Обратите внимание — я сказал "значения", потому что "переменные" — это всего лишь имена к значениям. У переменных свой глубокий внутренний мир, и про него во второй части.
Я продолжаю выразительно пересказывать документацию Ансибла и разбирать последствия её незнания (ссылка на предыдущую часть).
В этой части мы обсуждаем инвентори. Я обещал ещё и переменные, но инвентори оказалась большой темой, так что посвящаем ей отдельную статью.
Мы будем разбирать каждый элемент инвентори (кроме host_group_vars plugin) и обсуждать зачем он, как его использовать правильно, и как неправильно.
Оглавление:
inventory_hostname vs ansible_hostansible_user — писать или не писать?
Эта статья представляет собой обучающий материал, который предназначен для начинающих системных администраторов, поэтому опытным специалистам можно смело его пропустить. Публикация является продолжением цикла обучающих статей вот, вот.
В этом материале мы будем практиковаться писать Ansible role для автоматического поднятия web-сервера.
Мы продолжаем цикл обучающих статей для начинающих системных администраторов. В этом материале мы разберем Ansible, Ansible-Playbook, и как поднять полноценный веб-сервер с помощью системы автоматизации. Отметим, что если вы являетесь опытным администратором, можете смело пропускать данный материал.
Ведение
Приветствую читателей. В практике нашей компании часто появляется потребность в настройке серверов для простых односерверных проектов или небольших кластеров. В этой статье я бы хотел рассказать вам о нашем опыте подобной настройки, выделить особенности, которые могут вам пригодиться при дальнейшем администрировании. Статья предназначена для людей, которые только вникают в администрирование, а также для тех, кто самостоятельно администрирует свой небольшой проект и хочет набраться опыта в этом деле. Если вы являетесь опытным администратором, то можете смело пропускать данный материал.
Целью серии статей является описание подготовки работы сервера со стоком LEMP (Linux, Nginx, MySQL, PHP, Apache), развертывание стэка и поднятие на нем работающих площадок. Инструкция подойдет для небольших Bitrix проектов, а тажке для проектов развернутых под любой популярной CMS.
Не смотря на то, что тема уже достаточно подробно отражена в сети, мы решили подробно описать общие стандарты администрирования с нуля, по-скольку регулярно получаем большое количество базовых вопросов от людей, так или иначе, связанных с нашей сферой.
Большая часть проектов базируется на ОС Ubuntu, Debian в статьях будут отражены настройки для этих систем.
В данной статье будут описаны такие вещи как:
Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.
Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.
Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".
Наблюдаю интерес к этой теме. Могу рассказать о технике конца 70-х и позже. Что было интересным и потому запомнилось. Соответственно не будет энциклопедического изложения и картинок. Интересующиеся легко найдут недостающее за пару кликов. А здесь будут воспоминания непосредственного участника, и анекдоты на техническую тему.
Анонс. Электроника 60. СМ-3. СМ-4 .Электроника 100-25. Фрязинский дисплей. Проминь. БЭСМ-3М .ДВК.
Часть 1. Электроника 60
Профессия автора физик-экспериментатор, по факту инженер-ремонтник. Так совпало, что это было востребовано и интересно. Время действия начиная с 1977
Место действия - Ленинград, Петродворец, Ленинградский Государственный Университет (ЛГУ) Научно Исследовательский Институт Физики (НИИФ) Радиофизика.
Действующее лицо студент год поступления 1977. Мы с приятелем решили, что стандартный учебный процесс, лекции, семинары, лабораторные это не совсем то, чего хочется. Хотелось настоящего и сразу.И даже не настоящего, а будущего. До светлого будущего было рукой подать. В этом будущем были полеты в космос, везде вычислительные машины (слово компьютер было, не не общеупотребительно), новые города, населенные умными людьми – учеными и инженерами. Новый город уже был, ЛГУ в Петродворце. Оставалось найти умных людей. Так мы пришли в лабораторию кафедры Радиофизики. Нам невероятно повезло, мы сразу нашли себе Шефа, Умного Ученого и Инженера. Шеф как раз получил новую игрушку – электронику 60.
В СССР было Министерство Электронной Промышленности (МЭП). Производило оно много чего. Любое изделие МЭП называлось Электроника. И дальше буквы и цифры. В зависимости от которых изделие могло быть часами, игрушкой, магнитофоном, телевизором или компьютером. Электроника 60 была микроЭВМ.
Банковские сервисы по умолчанию не должны падать, и даже прилечь на секундочку, и даже когда мы обновляемся. Ведь даже секунды могут привести к потерям с множеством нулей. Чтобы этого не произошло мы используем blue-green deployment.
Простым языком blue-green deployment - способ развертывания, который позволяет обновлять приложения не отклоняя ни одного запроса, без остановок. Как это сделать, расскажу и покажу на примере. Статья подойдет DevOps-инженерам и бэкенд-разработчикам, особенно на HighLoad-проектах, а также моим будущим коллегам, как методичка по безрисковым релизам, чтобы прод не падал каждые 2 недели по графику релизов (а такое тоже бывало).
Доброго времени суток, друзья!
Изучение настоящей шпаргалки не сделает вас мастером SQL, но позволит получить общее представление об этом языке программирования и возможностях, которые он предоставляет. Рассматриваемые в шпаргалке возможности являются общими для всех или большинства диалектов SQL.