Vitaly Karasik

Добрый, Терраформ не очень хорош, его как end user. Для обновления используйте packer - лучше всего внутри CI/CD pipeline. После обновления ami обновите launch template в терраформе,просто указывая (новую) версию ami для ec2 машин.

Но... в терраформе можно указать user_data c баш скриптом для запуска во время инициации инстанса
https://www.bogotobogo.com/DevOps/Terraform/Terraf...

job:
  script: echo "Долгий тест!"
  rules:
    - if: '$CI_COMMIT_MESSAGE =~ /регулярка-стопслово/' 
      when: never

Для этого используются Gitlab-runner, разворачивается на сервере, создается нужный пайплайн, который при коммите в GIT будет делать всё сам.
Гуглить в сторону .gitlab-ci.yml gitlab-runner ci/cd pipelines

Ping может использовать различные способы получения IP-адреса (все перечислены в /etc/nsswitch.conf), например брать его в /etc/hosts.

Nslookup всегда запрашивает только nameserver.

Да, миграции, всё верно. Посмотрите в сторону Flyway или Liquibase. Вторым не пользовался, только читал, поэтому вкратце расскажу про Flyway. Он бесплатный в базовой функциональности, а её вполне хватает.

Миграции представляют собой SQL-файлы, названные по определённым правилам с указанием версии и краткого описания. Лично я вместо абстрактной версии использую текущие дату и время. Например, V20210601_1200__init.sql или V20210602_1015__alter_products.sql. Вручную файлы создавать скучно, я батник писал. Использование даты-времени позволяет создавать независимые миграции несколькими разработчиками параллельно и не особо обращать внимание на их порядок. Всё лежит в репозитории системы контроля версий вместе с остальным проектом.

При обновлении ветки кода (на стенде или на проде) запускаем flyway migrate. Он сверяет содержимое подкаталога с миграциями со своей служебной таблицей. Новые миграции применяются по очереди. К сожалению, здесь нет возможности отката миграции, как во фреймворках Yii или Rails.

Вкратце работа выглядит так:

• В репозитории создаём подкаталог, скажем, db с конфигурационным файлом flyway.conf (точнее, конечно, в репозиторий идёт flyway.conf.example, а конкретный конфиг настраивается под каждый стенд БД локально)
  
• Конфиг настраиваем на нужный экземпляр БД и подкаталог, где будут лежать файлы миграций, например db/migrations
  
• Описываем текущее состояние в самой первой миграции, я её обычно зову init. Она должна с пустой схемы обеспечить накат структуры и справочников до текущего состояния. Иногда лучше миграции разбивать на две: структура отдельно, инсерты отдельно.
  
• На тестовой базе выполняем flyway migrate и добиваемся того, чтобы миграция вкатывалась правильно. Откатывать придётся вручную, удаляя запись из служебной таблицы.
  
• Если всё нормально, коммитим результаты, выполняем flyway migrate на проде и наслаждаемся :)
  

По хорошему, конечно, вызывать механизм мигрирования нужно не руками, этим должен заниматься CI/CD (например, Jenkins) по факту обновления соответствующей ветки репозитория. Но для пробы процесса пока этого достаточно.

Vitaly Karasik

Евгений, я хочу это сделать Terraform

Terraform - инструмент для провижининга инфраструктуры. tf управляет ресурсами инфраструктуры и хранит их состояние в стейте для того чтобы просчитывать изменения при изменении параметров или кода
Пользователи на ваших серверах - это уже не инфраструктура, они никак не фигурируют (и не могут без костылей) в стейте tf, а значит именно управлять ими tf не будет.
Вы, конечно, можете использовать костыль в виде null resource запускающего просто sh\posh\cmd скрипт, который откуда то возьмет данные для подключения к вашим серверам, данные о пользователях которых надо создать
Терраформ этим ресурсом по сути не управляет, он только выполнит\перевыполнит(по триггерам на состояние других ресурсов в tf) ваш скрипт. О небезопасности хранения учетных данных таким образом думаю не стоит напоминать.
Аналогично вместо скрипта может быть ансибл\шеф (возможно через провайдер) или что-то другое так же запускаемое терраформом (но стейт созданных "ресурсов"=пользователей хранить будет опять же не терраформ, а значит об управлении речь не идет)
Не надо плоскогубцами забивать гвозди. Да, в некоторых случаях это возможно сделать, но это создает больше проблем чем решает
Кстати, намек как плоскогубцами забить гвоздь содержится в описании null_resource - ссылка выше.

https://wordpress.org/plugins/advanced-ads/ - скрываете рекламу для пользователей с определенной ролью (нужно будет создать роли для разных юзеров).
https://woocommerce.com/products/woocommerce-subsc... - сначала надо будет поставить WooCommerce. Потом с помощью этого дополнения сможете взимать деньги за отключение рекламы на месяц, на год и т.д. по подписке.
Третий вариант посложнее. Делаете сообщество с помощью https://wordpress.org/plugins/paid-memberships-pro/, далее уже для участников убираете рекламу (в про-версии плагина есть такая опция).

Используйте систему контроля версий (т.е. git). Вы всегда сможете посмотреть изменения, которые были сделаны и не занесены в production.
Полезная команда для вашего случая git diff, которая выводит изменения в файлах, которые еще не были добавлены в индекс. Сравнение происходит с последним коммитом.

xargs rm -i < a.txt

subsetofmultiset Бегло посмотрел код. Видно сразу что имеется определенное представление о слоистой/чистой/луковой архитектуре, возможно даже читал что-то из книг Эванса/Вернона по DDD и PoEAA от Мартина Фаулера, ну или как минимум какие-то статьи базирующиеся на информации из этих книг.

Довольно толково сделано. Единственное это то, что доменные сущности без поведения получились, состояние - есть, поведения - нет. Например следовало пету добавить метод любить человека, туда поместить бизнес-правила и если они все соблюдаются то создавать и возвращать из этого метода объект LovesHumanRelation и тому подобное. А так получилась что называется анемичная модель.

Но это всё можно быстро рассказать такому кандидату, дать почитать соответствующие главы из книг и будет реально толковый специалист. С такими знаниями не то что джуны, даже те кто сеньорами себя мнят ничерта подобного не знают. Одни ифоделы приходят (if-else-if-else).

Я так понял, для техлида то что ты написал получилось слишком сложно. Он походу хотел чтобы ты написал всё используя подход transaction script и готово, как это делают кнопкодавы.

Для меня, человек который вас не нанял - кретин. Показать бы ему что к нам приходит на собеседования за 100к.

При таком раскладе я бы шел итерационно. Сначала - бегло, все, в ширь. Т.е. просто понимаем, что, к чему и как устроено на этом предприятии. Но - повторю - поверхностно.
Следующая итерация - начинаем углубляться, причем в какой именно точке - подсказывают обстоятельства (что-то случилось) или статистика (что чаше всего случалось раньше). Опять углубляемся до решения конкретной проблемы, понемногу затрагивая и смежные вопросы (задел на будущее).
Если думаете, что человек, проработав 20 лет на одном месте не может столкнуться с новой для себя задачей , особенно в сфере ИБ - вы заблуждаетесь. Соответственно - комплексы "я чего-то не знаю" - отключаем сразу. Но да, особенно первое время придется учить много и постоянно, используя статистику предыдущих проблем. Не факт, что все запомнится, но основные опорные точки должны остаться в голове, и они в будущем, при возникновении реальной проблемы позволят вам найти решение быстрее и точнее.

Ну и главный лозунг - "не запоминаем, а понимаем". Многим трудно это понять после 15 лет школьно-университетского стиля образования. Но в этом и есть формула успеха. Особенно в современном мире, тем более в информационных технологиях.

Не знаю, на сколько прав буду или нет, но мне кажется там тоже сидят не дураки и деньги тоже умеют считать, даже с миллиардными доходами.
Но основная причина, как я думаю, в скорости разработки ......
У них же тоже есть дедлайны, планы, да и поддерживать проще один код, чем 2-3 версии его.

И дополню еще тем, что многое зависит от самое задачи и ПО, что и электрон один хорошо справляется со всеми задачами.

Нет, вы не можете в CloudFlare выбирать местоположение. Даже сам CloudFlare не может.

CloudFlare использует технологию anycast. В двух словах это когда один и тот же IP адрес анонсируется сразу несколькими географически разнесёнными дата центрами. И для посетителя из америки трафик будет приземляться на американский ДЦ, а для посетителя из россии на российский ДЦ даже если оба таких поселителя заходят на один и тот же IP адрес.

Поисковики в курсе этой технологии, так как сами ею пользуются. Так что география сайта не определяется ими исключительно по IP адресу.

принято ли в срезе разработки веб приложений СНГ писать коммиты на русском?

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

Но чем более подкованные специалисты в команде, тем больше вероятность, что они между собой договорятся все унифицировать и писать коммиты по конкретной схеме (это больше не про язык в вакууме, а про последовательность в проекте, чтобы было проще ориентироваться). Очень вероятно, что при этом выберут английский, т.к. скорее всего "русские" сообщения коммитов будут состоять из:

1. Англицизмов, которые еще и не имеют однозначной транслитерации в кириллицу, что ломает поиск по коммитам.
   
2. Названий классов, файлов, или еще каких-то сущностей из мира кода, которые и так уже переведены и есть в исходниках проекта на английском.
   
3. Набора базовых глаголов, которые ставят в начале предложений, вроде "добавил", "исправил", "удалил".
   

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