Что должен уметь Linux-администратор
27
15637
6 ноября 2020 11:06
6/11/2020
Visitors have accessed this post 15637 times.
Linux — это та операционная система, с которой вы точно будете работать в любой современной IT-компании. Знание ее изнутри, навык работы с ней при помощи разных инструментов — это тот фундамент, который поможет вам в дальнейшем развиваться в любом направлении IT.
Давайте посмотрим, какие шаги проходит в своей работе, что должен знать Linux-администратор.
Итак, что же нужно знать начинающему Linux-администратору? Предлагаем рассмотреть сразу на примере.
Допустим, у нас есть проект – нам нужно создать с нуля инфраструктуру Digital-агентства.
К вам пришел друг и говорит: «Хочу открыть Digital-агентство! Умею делать сайты и рекламу, знаю, где искать клиентов, но помоги настроить инфраструктуру, чтоб все работало, как надо».
Ну что ж, поможем другу и прокачаем свои админские скиллы.
1. Создаем офис
Что такое офис? Принтеры, бухгалтерия, у которой вечно 1С не работает, секретарша Людочка, у которой факс не отправляется, тегание сетей везде и постоянно… Ну да, так бывает. Но мы же грамотные ребята, можем и виртуальный офис сделать (а сейчас это — ой как актуально).
Итак, для нормальной работы нам нужны:
— телефония с гибкими возможностями,
— хранилище файлов,
— CRM-система.
И чтобы все это было защищено, недоступно извне просто так.
Звучит как план. Арендуем железный сервер у надежного поставщика, ставим на него Linux и начинаем:
— Ставим OpenVPN для подключения к инфраструктуре, скидываем другу профиль и инструкцию по подключению. Теперь настраиваем так, чтобы снаружи никто ничего не получил!
— Ставим NextCloud — получаем хранение файлов, CRM систему, вебморду для работы с почтой и все, что нужно для работы.
— Ставим Asterisk, подключаемся к виртуальной АТС. Настраиваем ее другу на телефоне, чтобы он мог звонить через нее. А на прием звонков настраиваем приветствие и автоменю, чтобы выглядеть по-взрослому.
Отлично, теперь можно работать! Но как клиенты узнают о нас? Допустим, у нас есть сайт-визитка, но его надо куда-то выложить.
2. Выкладываем сайт
Файлы у него простые — HTML, CSS, JS, никакого хранения не требуется.
Это мы быстро — берем виртуальный сервер (не наш же суперзащищенный офис использовать!), устанавливаем nginx, закидываем файлы, проверяем по IP-адресу, успех. Но использовать IP-адрес для сайта – как-то не солидно. Покупаем домен, прописываем DNS записи на наш адрес, обращаемся по адресу — успех, красота, хоть продавай!
Но теперь Not secure в Chrome не нравится. Мы же все безопасно делаем. Настраиваем Let’s encrypt для домена, подключаем к nginx и получаем защищенный сайт, который обслуживает себя.
И пошли звонки, но общаться по почте с mail.ru – хммм, не серьезно как-то. Поэтому переходим к следующему шагу.
3. Настраиваем почту для домена
Подключаем домен и управление им к публичной почте (к примеру, Яндекс). Создаем адреса себе, другу, менеджерам, секретарше Людочке, белому медведю Валере и всем, кому требуется, – вот теперь все серьезно!
И вот наконец первые заказы. Но тут мы понимаем, что как-то каждый раз вручную закидывать в базу файлики с прайсами и бланками заказа не комильфо.
4. Автоматизируем выкладку
Сначала все просто — заказываем виртуальную машину, настраиваем на ней nginx, DNS домен клиента уже настроили, Let’s encrypt есть. Осталось главное – контент, который будем выкладывать.
Друг знает один путь — поправил инфу в файлике, отдал тебе, выложили. Изменилась информация – снова по этому же пути. Но вас терять на это время не прельщает.
Поэтому мы, как истинные (=ленивые) администраторы, делаем скрипт, который из директории с NextCloud через rsync синхронизирует файлы на сервер клиента каждую минуту. Проблема вроде бы решена, хотя и пахнет костылем. Казалось бы, что может пойти не так? Вот тут мы уже подходим к серьезной работе, той, что в первую очередь должен знать Linux-администратор.
Проходит время, и клиенту нужно сохранять и отдавать данные, а значит, их нужно где-то писать и хранить. Друг все данные собрал, но вот виртуальный сервер к этому не готов. Опять работа!
5. Делаем базу данных и PHP-FPM
Пока все просто — устанавливаем MySQL, PHP-FPM, настраиваем его на работу с нашим приложением. Затем настраиваем nginx на работу со всем этим добром и готово, живем, как прежде.
Но в какой-то момент друг случайно удалил файлы из хранилища и файлы с сервера пропали тоже (костыль-выкладка выстрелила в ногу. И снесла полголовы), оставляя клиенту голый сайт. Непорядок! Да, данные мы вернули (спасибо Next Cloud за это), но надо что-то менять в нашей системе.
Пожалуй, пора расти технически и нанять PHP-программиста, хорошо бы, чтобы он и в Git умел.
Но для этого нам нужно Git-хранилище – разворачиваем на своем сервере GitLab и переносим туда сайт. Но нужно еще сделать выкладку – теперь по-умному.
6. Автоматизируем выкладку. I’ll be back ©
Пишем через GitLab CI сценарий выкладки, чтобы по коммиту все синхронизировалось также по rsync. Теперь можем в любой момент вернуть старый код, нажав нужную кнопку. Красота!
И тут мы понимаем, что, кажется, чуток заступили на территорию DevOps. Вот это да! Раздуваемся от гордости и думаем, как и что сделать лучше. А тут – epic fail. Данные одного из клиентов в базе данных потерялись! Беда, стыд, позор! Срочно надо сделать так, чтобы данные не терялись или их хотя бы можно было вернуть.
7. Делаем бэкапы
Решаем, что для каждого клиента нужно делать бэкапы базы данных. Не забывай делать бэкапы — одно из правил, которые должен знать каждый Linux-администратор. Код у нас уже хранится в Git, а значит, его в случае чего восстановим. А вот с базой не все так просто.
Для этого арендуем сервер с большими дисками и настраиваем на него бэкапы, которые снимаются каждую ночь с каждого клиента и отправляются на сервер к конкретному пользователю по rsync с глубиной хранения в неделю.
Теперь данные будут в сохранности.
Но неправильно, что о проблеме мы узнали от клиента, а не увидели ее сами. Надо бы это исправлять.
8. Настраиваем мониторинг
Настроим на нашем сервере Prometheus сервер, который собирает доступность сайтов клиентов, сервера и, заодно, проверяет информацию о доменах клиента. С появлением бэкапов бдим и место на сервере. И для надежности делаем так, что в случае чего — в Telegram бот просигналил о беде.
Итак, после всех проделанных шагов мы получили систему, которая работает и принимает заявки клиентов, разработка идет, выкладка работает, мы за всем наблюдаем и спасение базы данных продумали.
То есть, мы сделали защищенный контур компании со всей требуемой инфраструктурой, возможностью подключения новых клиентов, автоматизированной выкладкой приложений, бэкапами и мониторингом доступности. И вполне заслужили звание системного администратора Linux. И конечно, получили базовое представление о профессии (или кто такой Linux-администратор).
От редакции
Если вам интересно посещать бесплатные онлайн-мероприятия по Linux, DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN.
*Анонсы мероприятий каждую неделю
Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.
Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.
Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.
А потом начинаются жалобы что наш сайт в Хабаровске тормозит так как наш датацентр находится в Москве(а то и в Сан-Хосе). Оставляем на виртуальном сервере только API, статику закидываем в Cloud Storage, Прикручиваем к нему CDN, к CDN прикручиваем SSL… раскатываем это всё разумеется Terraform’ом.
Понимаем что для бекапов держать отдельную тачку дорого и вспоминаем про Cloud Storage, перенастраиваем…