Vitaly Karasik

Ну это же просто.
Вместо этого бреда

readinessProbe:
          initialDelaySeconds: 15
          exec:
            command:
              - find
              - /var/www/public/live777.html

выполняйте в качестве рединесс пробы HTTP или даже сокет реквест на ваш сервис. Пока он не поднимется, трафик не будет идти на это контейнер.

readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 30

Проблема ещё в том, что апач прожорливый, и если пытаетесь защититься при помощи .htaccess от множества запросов - то скорее всего, эти запросы уже положат апач. А ещё, если адресов в чёрном списке будет много - то это сильно замедлит легитимные запросы, потому что при каждом запросе должен будет читаться и парситься .htaccess, который будет очень сильно расти.
Потому блокировать нужно явно ещё раньше, к примеру, средствами брандмауэра (если не рассматривать внешние способы защиты, при которой эта задача ложится на хостера или промежуточное звено вроде cloudflare, а до сервера доходят уже отфильтрованные запросы).
При большом объёме - чёрный список должен быть не линейным, т.к. время O(n) нас явно не устраивает, проверки наличия адреса будут занимать много времени, поможет к примеру ipset, хранящий отмеченные адреса в виде хэш-таблицы.

Оффтоп. Извините, не сдержусь. Раз 2 недели, значит карантин выдержал.
У меня было такое из-за провода

1. Включить логирование медленных запросов MySQL, после чего оптимизировать, добавить индексы.
   
2. Обратить внимание на то, что индексы могут приводить и к падению производительности, так что неиспользуемые лучше удалять.
   
3. Убедиться, что не просто индексы проставлены, а проставлены правильно.
   
4. Включить логирование atop на несколько дней, чтобы была возможность понаблюдать, что происходить в системе, когда "начинает виснуть всё". Может быть, вообще не в MySQL дело?
   
5. В Laravel запросы делаются к базе с помощью Active Record - бывает так, что вместо JOIN в базу летит гора запросов циклом - это не оптимально.
   
6. Как уже выше писали, нужно использовать кеширование - это ощутимо снизит нагрузку.
   

Плохая мысль. Если у вас AD integrated DNS - будут серъезные проблемы с динамическим обновлением записей.

Можете поэкспериментировать с экспортом-импортом записей, либо создать связку primary secondary зон и по идее primary DNS сервер должен слить все данные на slave\secondary linux

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

Во-вторых, проблема "выгорания" - это проблема психологии. Мне такие проблемы при удаленной работе попадались один раз. И честно говоря, даже при офисной работе с ними справиться не легко - но тут как-бы человек на виду, всегда можно поговорить на диванчике, за чашкой кофе. А на удаленке контакт значительно слабее, поэтому надо сказать , что и шансы на успех будут на порядок ниже.
Вы должны вообще-то говоря понять, что как только вы - как работодатель и как исполнитель - приняли решение об удаленной работе - все личные проблемы исполнителя остаются вне поля вашего внимания. Вы должны его об этом поставить в известность сразу-же. Это его плата, которую он несет в обмен на удобства его работы дома. Он должен понимать, что это не он, это вы согласились на то, что-бы он не тратил время-деньги на дорогу, на присутсвие в офисе, на завязывание галстука и шнурков на ботинках, на жесткий контроль часов и т.д. "Выгорел" - это не COVID-19 подхватил, не ногу сломал, упав с дивана и не кошка любимая заболела, срочно надо к ветеринару. "Выгорел? - ну пойди соберись и работай дальше. Не можешь - поезжай на Бали, расслабся, как вернешся - подавай резюме на свободную к тому моменту вакансию, тогда и будем решать". Тем более, что участник проекта из новых, а с новыми - всегда легче прощаться, чем с теми, с кем ты сделал десяток проектов. И после десятого совместного проекта я бы "выгорел" - еще потерпел-бы, дав человеку передышку. А если это начинается на втором-третьем месяце первого проекта?

Еще одно. "Выгорел" - это один кейс. "Сотрудник снес свой код, сорвав дедлайн" - это совершенно другой. Вообще-то говоря он нанес вам (вашей фирме) урон, материальный. Вы с ним об этом говорили? Вы ему объясняли, что срыв дедлайна - это удар не по абстрактной фирме или абстрактному заказчику - это в первую очередь удар по коллегам, работающим вместе с ним на проекте. Возможно - лишении их премии. Вы спросили его, как он собирается компенсировать этот урон? Что он вам ответил?

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

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

Второе - "удалил код". После такого - решение однозначно. Прощание без финансовой компенсации, без сожаления и без "простите меня пожалуйста".

Ну вот как-то так.
Удачи вам в решении проблемы.

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

Да

Каковы реалии?

Работа есть, работа разная, есть говно есть крутотень, все как везде. От факта "удаленки" мало что меняется уже в современном мире (на дворе уже даже не 2000-е)

Какие условия ставят работодатели?

По моему опыту - работодатели готовые к удаленке заметно адекватнее "офисных", и условия обычно лучше и разумнее. Хотя сейчас возможно с массовым переходом на удаленку станет по другому, но этого никто не знает

Насколько сильный контроль за удаленщиками, насколько работодатель отличается от офисного работодателя? Желания попадать в рабство, где будут препарировать за каждую строчку кода тоже нет. Работал в подобных коллективах, хватало максимум на год.

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

Смотрите переменную path все что в ней то запускается

Любой прокси + отправка его логов в ELK. В кибане сможете строить какие захотите отчёты - хоть по айпишникам, хоть по урлам с доменами.

Разница должна быть обязательно расширением базовой функциональности (статически - через наследование), либо работать через стандартизированный интерфейс (динамически - API для плагинов).
Костыли с кучей if лучше заменять полиморфизмом, используя IoC via DI и идею паттерна Стратегия.

Детальную девелоперскую документацию вести нет смысла, как показывает практика - ее трудно поодерживать. Можно завести вики или даже документы, в общих чертах описывающих работу тех или иных неочевидных узлов.
С точки зрения логики работы приложения, в сурёзных конторах QA пишут тест-кейсы, которые фиксируют требования. Это бывает полезно, чтобы освежить память. (тест-кейсы не устаревают, ибо каждый релиз прогоняется полный регрессионный цикл)

Должен/не должен это не эффективный подход.

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

Иначе - будет стагнация как у некоторых персонажей, которые "не обязаны выполнять не свою работу", и при этом в соседних темах ноют что уже 10 лет никаких проблесков в карьере, зп какая-то нищенская, и кроме как забухать ненавидя всех вокруг ничего не остается.
Если этот вариант вам не подходит - то берете мануалы и вперед. Их много хороших, вот например https://www.digitalocean.com/community/tutorials/h...

Дальше уже идете на тостер с конкретными проблемами а не вопросами "меня тут заставляют работать больше чем предполагалось"

Самый идеальный вариант - подойти к кому то у кого этот проект уже поднят и попросить помощи.
Даже если вы разберетесь как поднимать сервер, то всегда могут быть какие-то нюансы которые нужны именно на этом проекте и которые вы просто не можете знать, а правильно - подойти и спросить.

Смотрите на это под другим углом. Нет строго определённых критериев что верстальщик должен уметь а что нет. У каждой компании они свои. И в ваших интересах уметь то, что нужно для большинства компаний на рынке. Конкретно для этой вы должны уметь поднимать сервер. А в другой вы должны будете работать с git. А в третьей общаться на немецком. А где-то вас могут не взять, уже потому что коммуникативные навыки у вас слабые, и другим работать с вами не комфортно.

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

По-хорошему лучше монтировать в докер-контейнер volume с данными: держать данные отдельно от движка.

docker run --name some-mysql -v /my/own/datadir:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag

### или создать дата-volume и его приделать к контейнеру
docker volume create data_volume
docker run --name some-mysql -v data_volume:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag
### так после выключения контейнера данные не пропадут, останутся в этом data_volume, 
### который можно скопировать, подключить к другим контейнерам

Но, тем не менее:

Вариант 1.
Экспортировать в папку на хосте данные из базы с помощью mysqldump или какая там у вас база. Бэкапы, в любом случае, делать необходимо. Поднять копию контейнера, импортировать в неё данные из дампа. Примеры команд для mysql в docker см. внизу в секции Creating database dumps:

### Creating database dumps
docker exec some-mysql sh -c 'exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD"' > /some/path/on/your/host/all-databases.sql

### Restoring data from dump files
docker exec -i some-mysql sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"' < /some/path/on/your/host/all-databases.sql

Вариант 2.
Сохранить текущее состояние контейнера через docker commit — получится новый образ со всеми изменениями. Запустить его как копию.