Технические рекомендации и лучшие практики для учебных пособий DigitalOcean

Это руководство является попыткой обобщить установленные передовые практики и убедительные рекомендации для авторов учебных пособий DigitalOcean. Он призван обеспечить основу для согласованности, технической корректности и простоты использования в учебном материале DigitalOcean.

По своей природе это и незавершенная работа, и самоуверенный документ, основанный на растущем опыте внутренних технических писателей и редакторов, общественных менеджеров и инженеров. Его рекомендации могут быть изменены и написаны специально для образовательного контента с учетом широкого круга читателей и конечных пользователей.

В системах Ubuntu и Debian должен бытьunattended-upgrades с как минимум установленными и настроенными обновлениями безопасности. Мы не рекомендуем автоматически перезагружать или обновлять все, учитывая контекст.

Обычно мы рекомендуемsudo apt-get dist-upgrade вместоsudo apt-get upgrade, внимательно изучив предлагаемые изменения, чтобы убедиться, что ничего деструктивного не происходит. Эти две команды очень похожи, но использованиеupgrade может быть менее предсказуемым, поскольку некоторые изменения сдерживаются. Задержка определенных пакетов может привести к несоответствию версий, что может вызвать проблемы с производственными системами.
Мы продолжим использоватьapt-get в Ubuntu 16.04 из-за отсутствия документации дляapt и некоторых турбулентность по поводу предпочтительного менеджера пакетов дистрибутива.

Обязательно используйте системные системные команды init, даже если доступны устаревшие команды совместимости. Например, используйтеsudo systemctl start [service_name], даже еслиsudo service [service_name] start будет работать.

Предоставьте информацию о том, как включить или отключить запуск службы при загрузке. Укажите, как проверять результат выполнения команд, связанных со службой, если интерфейс не указывает явно (journalctl -u,systemctl status и т. Д.).

Предпочитайте перезапуски по перезагрузкам для сервисов, как правило. В большинстве случаев более важно обеспечить известное состояние, чем избегать прерывания обслуживания на доли секунды, и перезапуски также более полезны в случае полного отказа службы.

Если это не часть рабочего процесса управления конфигурацией, вы предпочитаете сценарии пользовательских данных и в большинстве случаев сценарии cloudinit для создания сценариев в пользовательских данных.

Объясните, где и как получить доступ к журналам для установленных служб. При необходимости объясните командыsystemctl иjournalctl для проверки состояния службы и вывода журнала. Там, где это возможно, предлагайте краткие предложения по диагностике распространенных случаев отказа.

Обязательно выполняйте ротацию журналов в любых случаях, когда они не обрабатываются пакетами или другими механизмами установки.

Для следующих файлов журналов с открытым текстом используйтеtail -F, а неtail -f, поскольку последний не будет отслеживать переименования файла и может вызвать путаницу, если журналы чередуются, когда пользователь просматривает их.

Создайте пользователейsudo вместо прямого использования root. Обратитесь к соответствующим руководствам по начальной настройке сервера, которые объясняют эту задачу как обязательное условие.

В дистрибутивах на основе Debian добавляйте и удаляйте пользователей сadduser sammy иdeluser --remove-home sammy соответственно; в дистрибутивах на основе RHEL используйтеadduser sammy (при необходимости установите пароль с помощьюpasswd sammy) иuserdel -r sammy.

Предоставьтеsudo привилегииusermod -aG sudo sammy в Ubuntu. CentOS немного сложнее. Современные версии используютusermod -aG wheel sammy, но некоторые версии требуют, чтобыvisudo сначала раскомментировал разрешения группыwheel. В частности, в CentOS 5 необходимо установитьsudo и раскомментировать группуwheel с помощьюvisudo; в CentOS 6sudo уже установлен, ноwheel нужно раскомментировать; CentOS 7 имеетsudo, а группаwheel уже настроена.

При использовании команд с повышением привилегий обязательно проверяйте их как написано. Чтобы передать переменные среды черезsudo, используйтеsudo -E command_to_run (если доверено всей среде) илиsudo FOO=BAR command_to_run. Для экземпляров, которым требуется корневая оболочка, используйтеsudo -i. Для экземпляров, требующих перенаправления, используйтеtee -a для добавления, а не для замены файла назначения:[sudo] command_to_run | sudo tee [-a] file_to_change.

Для интерактивных оболочек, предположим, Bash в системах GNU / Linux, упоминается явно, когда это уместно. Во FreeBSD используйте tcsh, так как он доступен из коробки и имеет полезные функции.

Для текстовых редакторов мы включаем копию «использовать [предпочтительный] или ваш любимый текстовый редактор» и включаем следующие удобные для начинающих редакторы в команды для этих копий и вставок. В Linux мы по умолчанию используемnano; во FreeBSD мы по умолчанию используемee. vi (m) допустимо, но избегайте его в вводных темах, где он может стать камнем преткновения для начинающих.

Для передачи файлов мы обычно рекомендуемsftp в большинстве случаев для его интерактивного и похожего на scp использования, хотя в нем отсутствует функция push, поэтомуscp также приемлем. rsync полезен для резервного копирования и передачи больших файлов (или множества небольших файлов). Не используйте FTP ни при каких обстоятельствах. Мы также стараемся стандартизироватьcurl по сравнению сwget из-за его надежности. Преимуществоwget в основном заключается в рекурсивной загрузке (т.е. особый случай использования, который не является распространенным для нашего вида контента).

На машинах, которые поставляются с утилитамиiproute2, мы предпочитаем их наборуnet-tools, то естьconsidered obsolete. Как правило, утилитыiproute2, такие какss, будут лучше поддерживать несколько интерфейсов, IPv6, новые функции ядра и т. Д. Точно так же мы должны использоватьip route вместоroute,ip addr show вместоifconfig и т. Д. Иногда вывод старых утилит по умолчанию немного чище, но сам вывод менее надежен, поскольку они также не обрабатывают крайние случаи. По возможности мы будем контролировать более подробный вывод, используя доступные флаги.

В контексте руководств по системному администрированию, как правило, избегайте длинных пользовательских сценариев и длинных сценариев оболочки.

Сценарии, написанные автором (и, возможно, другие ресурсы), должны размещаться в репозитории отдельных статей в учетной записи GitHub сообщества Do-Community со ссылкой на опубликованное руководство. Следуйте хорошей практике сценариев в целом. Например, поместите любые переменные, которые пользователь должен будет заполнить, в верхней части скрипта, желательно в хорошо помеченном разделе. Также обязательно прокомментируйте усердно; тело сценария, встроенное в учебник DO, не должно функционировать как черный ящик. Пользователи должны быть в состоянии выяснить смысл, прочитав его до конца.

Предпочитайте/bin/shbash и избегайте специфичных для Bash функций, когда проблема переносимости или кроссплатформенного повторного использования. Используйте оболочки и coreutils / стандартные инструменты Unix для небольших задач; Избегайте введения новых зависимостей исключительно для задач на языке клея, если только преимущества не являются существенными. Предпочитайте#!/usr/bin/env interpreter до#!/path/to/interpreter.

Как правило, используйтеcron для планирования повторяющихся задач, но также можно использовать таймеры systemd.

При загрузке сценариев или данных убедитесь, что пользователь находится в доступном для записи каталоге или что пути явно указаны. Для файлов, которые должны быть доступны для ссылки или повторного использования, используйте домашний каталог пользователя, если они не принадлежат какому-либо стандартному четко определенному пути в другом месте файловой системы (например,/opt или/etc). Для одноразовых файлов используйте/tmp.

Мы рекомендуем каталоги конфигурации в стиле Debian для дистрибутивов, которые не структурируют его по умолчанию. Всегда проверяйте изменения конфигурации (Apache используетsudo apachectl configtest, а Nginx используетsudo nginx -t).
/var/www/html должен использоваться как корень документа для всех веб-серверов. Значение по умолчанию/usr/share/nginx/html для Nginx следует изменить, поскольку этот каталог принадлежит и потенциально может быть изменен обновлениями пакетов. Это больше не является проблемой в Ubuntu 16.04, но останется актуальным для предыдущих выпусков.

Двигаясь вперед, предпочитайте создавать новые файлы виртуального хоста Apache или файлы блоков сервера Nginx, а не изменять предоставленные файлы по умолчанию. Это помогает избежать некоторых распространенных ошибок и поддерживает файлы по умолчанию в качестве резервной конфигурации, как и предполагалось.

Шифровать и аутентифицировать все соединения между системами. Не поощряйте (явно или неявно) пользователей отправлять учетные данные или передавать непубличные данные в открытом виде.

В частности, пароли и материал ключа не должны передаваться по незащищенным соединениям. Соединения с базой данных, ведение журнала, управление кластером и другие службы в идеале должны быть всегда зашифрованы. Веб-панели управления должны иметь видserved over HTTPS connections, а TLS / SSL следует использовать для служб, где он поддерживается. Общедоступные сервисы, такие как простой HTTP, допустимы, поскольку пользователи могут по-прежнему хотеть или нуждаться в их предложении, но в общем случае их настоятельно не рекомендуется, особенно для динамического контента.

Избегайте практики, которые представляют собой низкую выгоду безопасности из-за неясности или театральности, например, изменение порта SSH по умолчанию. Настройте брандмауэр. Наши рекомендации для конкретных дистрибутивов:ufw для Ubuntu,iptables для Debian иfirewalld для CentOS. Однакоiptables наиболее согласован на разных платформах и имеет множество инструментов, которые к нему подключаются.

По сути, это самоуверенный, живой документ, который будет часто обновляться. Технологии быстро меняются, и мы в DigitalOcean делаем все возможное, чтобы не отставать, но если вы заметите какие-либо ошибки или у вас есть отзывы, мы будем следить за комментариями ниже.