Comments 29
Неглубоко копаем, где инструкции по восстановлению работы, я уж помолчу про их практическую тренировку?
Это основные метаправила системного администрирования.
Тут до восстановления работы еще не дошло. Тут все что до восстановления работы, судя по всему.
Тут написано о том, как делать, чтобы ничего не нужно было восстанавливать. Не ремонтировать, а заранее выстраивать систему так, чтобы меньше сбоило и быстрее восстанавливалось.
Просто некоторые считающие себя сисадминами, не принимают и не понимают о чем там эти ваши пролежат фениксы, sre и прочее.
Они делают "хорошо". Надежно, один раз и на века. (Обычно потому что уже через пару дней не помнят что и как делали.) они очень любят главное правило сисадмина "работает - не трогай". Поэтому когда не работает, они уже и не знают что же нужно потрогать, чтобы опять работало. Иногда они даже не будут знать что что-то не работает. Вот эта статья для них и про них. Да эти ребята действуют по "стандартам" начала 00-х, да они где-то рядом с вами. Возможно вы их ещё не заметили, потому что все работает и они ничего не трогают. Но они есть, и они рядом. Возможно прямо сейчас к вашим контейнерам кто-то прикручивает свой "полезный" скрипт.
Не надо недооценивать сисадминов.
Зайти на контейнер для записи и сделать
echo ... > /etc/hosts
Дочитал до сюда, вспомнил про extra_hosts, понял, что читать дальше не стоит.
А зря. В смысле, зря вы про extra_hosts вспомнили: проблему неправильных записей DNS надо на стороне DNS решать, а не через hosts в любом виде.
Эм. Вы точно понимаете, для чего docker-compose нужен?
Все верно, вносить изменения в /etc/hosts на докере это неправильно.
Как раз в случае с compose это и есть правильный путь. Compose должен подниматься локально и работать на любом хосте - иначе он не нужен. Как туда трафик придёт от ingress - это уже другой вопрос, но проект должен заводиться локально и работать без дополнительных подпрыгиваний.
Если кривая запись в dns, а описан именно этот случай в статье, то править наверно надо именно в днс.
В статье описан случай "мы не разбирались, что происходит". Я же оспариваю тезис: "Все верно, вносить изменения в /etc/hosts на докере это неправильно."
Вносить такие изменения - правильно, более того - для этого есть штатный механизм в compose.
А вот контейнерам ходить к друг другу через dns (и, очевидно, через внешние адреса и/или ingress) - может быть неправильным в миллионе ситуаций. Уж светить дырявый recording-server jitsi куда бы то ни было точно не стоит.
Да, это может быть правильно. И да нсть штатный механизм.
Докер тут видимо появился просто потому-то что он был. Но для демонстрации примера "нефиг прикручивать костыли" подходит отлично. Так как демонстрирует и игнорирование штатного функционала выбранного инструмента. И локальный костыль вместо решения проблемы. (Для всех остальных запись в dns так и осталась с ошибкой).
И самое важное – когда поддержка работает, плохо всем.
Поддержка должна не работать и получать за это деньги.
Это правило работает только для случаев, когда есть второй сервер!
Зависит от типа инфраструктуры. Если у ваших клиентов протух cross-signed сертификат LE, то вы можете сколько угодно рассказывать про то, что "оно работало в пятницу, должно и в понедельник".
Делать бекапы же!
У меня есть два альтернативных названия для статьи:
"Конспект подготовки начинающего эникейщика к принятию в ряды джуниоров эникейщиков"
или
"Главный сисадмин уехал в командировку и оставил джунам записку следущего содержания.."
Простите за подколы, но правда, уже на дворе IaaS, PaaS, виртуализация, контейнеризация и прочее, и такие "проблемы" уже должны давно стать историей. Т.е. человек без специальных знаний и доступов физически должен быть не в состоянии накосячить, а о сбоях в системе ты должен узнавать по мониторингу быстрее чем пользователь успеет написать тикет.
Во всяком случае это то к чему стоит стремиться.
По три кластера кубернетеса в aws с бигдатой и пачкой sre в каждый ларёк!
Причём всё это "как оно должно быть" чаще всего работает только у маркетологов или на конференциях. Ну и ещё в книжках.
А в суровой реальности все сурово и реально. Даже то, что кажется полным бредом.
Вон в соседнем посте милая девушка рассказывает как они катили микросервисы в прод без тестов. И куда прикатились.
Это все правильные правила, только вот такой подход не решает проблему в корне, следуя своим же правилам.
У нас, например, билды время от времени падают, потому что таймаут в корпоративном репозитории докера. И это известно админам но не чинится почти год.
Я понимаю прекрасно о чем в статье говорится. Это определенный подход к работе. Больно то, что об этом вообще нужно говорить. Для меня это вещь сама собой разумеющаяся. Я когда пишу автоматизацию пытаюсь привести все к стандартному виду, при попытке осмыслить ошибку спускаюсь вниз по стеку, туда где без документации уже не разберешься. Копаться, составлять технически достоверную картину ошибки, мне это не "влом". Ведь я понимаю, если еще и я ослаблю хватку, то лучше точно не станет. Во время любого рефакторинга и архитектурных изменений автоматизации рабочее решение всегда продолжало работать, и только после тщательной обкатки на отдельной ветке менялось на новое. Это профессиональный подход. А как иначе?
Или у нас чтобы развернуть рабочее окружение, нужно какой-то ява пакет добавлять вручную, потому что его ни в каком мавен репозитории нет. И говорить разрабам о том что так не должно быть, и даже экзотическую библиотеку нужно тупо добавить в корпоративный nexus, чтобы maven отрабатывал чисто - все равно что стучать по стеклу аквариума пытаясь привлечь внимание рыбки.
Поэтому слышать от сисадминов "мы знаем об этой проблеме", мягко скажем, обидно.
А, вспомнил как это называется - пох*изм и некомпетеность.
Первое и всегда первое правило Системного администратора - Разделяй и властвуй!
Разделяй на всех уровнях OSI и одно не потащит за собой другое.
Не потребуется перегружать один сервер с кучей сервисов, когда сервисы разделены на отдельные виртуалки и т.д.
А вот первое правило Инженера - Техника должна работать!
Если техника не работает, то у инженера 2 пути.
Либо починить технику, либо выкинуть, заменив рабочей.
Из года в год появляются те, кто знает как и что нужно делать, но мир почему-то не наврдняется ромашками и розовыми пони. Не стоит из своего опыта лепить инструкции как надо жить. Вы не видели и 1% того разнообразия решений и ситуаций, которые реализуются в мире прямо сейчас. Описывайте свой опыт, но не преподносите это как серебряную пулю.
нестареющий анекдот про дом, который построили заднеприводные: на каждом этапе появляется специалист, который говорит заказчику - ну что за заднеприводные тут так сделали?!
Правило 1. "Ничего не трогай, пока это работает" - это не для Windows-машин. Выходит новое неудаляемое обновление - и вуаля! Отваливаются принтеры и NAS'ы 3-х и старше летней давности. Причем решение бывает своеобразным - установка новой сетевой карты и перенастройка правил FireWall'а для неё.
Могу еще много интересного рассказать про виртуальные машины Hyper-V, особенно про то, когда для них по непонятной причине создаются снэп-шоты с потерей данных. Причем наследование работает только от корня к ветке, но не в обратном направлении. Руцями, хоть Инет полон "советами и решениями".
Правило 2. Про перезагрузку по требованию. Когда-то ставил и настраивал Kerio Control. 6-я или 7-я версии устойчиво работали максимум неделю. Затем - сбои и глюки, вплоть до полного отказа.
Правило 3. Два сервера купить? Или жить в офисе? Удаленная настройка из BIOS - да, если железо позволяет. А вот второй жесткий диск для загрузки подставить удаленно - сложновато.
Причины, которые можно “принять”: ...Годзилла проснулся и разворотил город
Хочется уточнить: отсутствие бюджета на железо и софт - является ли отмазкой инженера, на которую не стоит покупаться? Иными словами, должна ли у хорошего инженера всегда хорошо работать система, если эту систему инженер собрал из пластилина и палок (речь о регионах)?
Золотое правило системного администрирования