Димон Дурак

Это болючая задача которую мне приходится решать на каждом проекте.
"Готовое" решение для симфони - liip imagine bundle, но пока все конфиги изучишь - неделя пройдет.

Я обычно подключаю вручную:
1. свой класс отвечающий за масштабирование + обрезку + смену формата на webp
2. 2 маршрута API - один называю blueprint, второй image. Блюпринт выдает JSON-ом все возможные ссылки с предустановленными параметрами, а image - отдает картинку
3. и оборачиваю это в phpleague flysystem, чтобы при случае переключиться на амазоновское, дропбоксовое или свое собственное хранилище, а изначально использовать родную файловую систему
4. для обрезки подключаю gumlet, он может не идеален, но немного проще чем использовать встроенный gd или устанавливаемый imagick, где придется учить настройки, гумлет все-таки немного преднастроен по качеству и сжатию (под капотом все равно gd или imagick используется, просто обертка)

Вот пример на тестовом сайте:

/api/v1/uploads/image/2024/02/000029_1605538227_415880_big1.jpg?presets=group.all
/uploads/image/size-original/2024/02/000029_1605538227_415880_big1.jpg
/uploads/image/size-jpg2webp/2024/02/000029_1605538227_415880_big1.webp
/uploads/image/size-jpg2webp-100-100/2024/02/000029_1605538227_415880_big1.webp

Но там много моментов, которые так просто не описать.
1. Во первых сначала масштабирование. Тут придется думать по длинной стороне, короткой стороне, или по aspect ratio.
2. Потом обрезка, если идеально привести не удалось. Отдельно придется подумать где точка центра - вверху-центре или в центре-центре.
3. Потом после обрезки скорее всего ты получишь raw content изображения, чтобы его сохранить в файл нужно его поймать ob_start()/ob_get_clean(), и обеспечить чтобы входящая ссылка всегда приводила к созданию картинки с тем же путем, и если она уже есть - не тратила время а отдавала готовую. Опять же - если сделать "произвольный размер" - то твой сервер очень легко нагнуть, сделав мини-ддос, чтобы он сгенерировал все возможные сочетания размеров от 0 до 2000 по X/Y, получится 4 миллиона картинок. Поэтому так или иначе надо предусматривать ключ или пароль, позволяющий это делать, чтобы снаружи не долбили ерундой.
4. Потом форматы. Родное изображение было в .jpg, а итоговый хочется webp. Получается что итоговое изображение будет либо с двумя расширениями (и пхпшная функция pathinfo еще заставит попотеть), либо оригинальное разрешение будет получено из jpg2webp, а итоговое можно указать любое, но работать должно только если оно webp.

В общем, гемор что надо тебя ждет. Но реализуемо.

Например, для единичного компа можно так

Get-CimInstance –ComputerName CLIENT1 –ClassName Win32_ComputerSystem | Select-Object UserName

Для множества компов - запихать вышеприведенный код в цикл и обходить все компы домена или выборочно по списку

Использовать докер в продакшене - нормальное решение?

Да, но есть один нюанс... Судя по вашему вопросу, вы его точно не учли.

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

Выкидываете build и git, создаёте docker registry, предварительно собираете образы (без гита, только полезные файлы в slim образе), пушите их в реестр, на проде прописываете нужные образы нужных версий. Поднимаете через compose + устанавливаете restart = unless stopped.

после чего память на сервере закончилась

Выкидываете git, делаете docker system prune раз в месяц, ставите в настройках демона ротацию логов.

Автоматический бекап базы данных - ответственность самого сервиса (в коде делать дамп), докера (использовать какой-то image для бекапов) или сервера (непосредственно на сервере настроить крон)?

Docker image не используется для бэкапов, потому что он не может изменять свои файлы. Файлы изменяются в контейнерах, volume или маунтах.
Поэтому бэкап - это задача сервера. Только бэкапить надо не рядом с базой, а на другой сервер.

Как не терять данные из бд при перезапусках контейнера?

Контейнер не теряет файлы при перезапуске. Скорее всего, вы его тупо удаляете, а затем пересоздаёте.

Но тк приложение работает в докере, я не могу выполнить nano app.logs для просмотра логов.

Писать логи в другое место/ docker attach / docker cp / экспорт логов и метрик в сервис мониторинга.

p.s.
Вот вам линтер для обучения.

Зайду немного с другой стороны и опишу неочевидные новичку вещи...
1) Про "мощность" забудьте, она ниже плинтуса. Но нужен ли вам только контроллер домена? А будет к нему файловый сервер? А желателен ли ему дисковый кэш? А будет дедупликация данных и DFS?
2) Да, старые ОС иногда есть смысл ставить сначала, создавать домен на них, но потом сразу и обязательно мигрировать на свежую ОС и выводить старый из работы. Иногда это решает проблему странных специфических глюков совместимости в разнородной среде. Но ваш ли это случай?
3) Лишнего избыточного не надо, но второй обязателен. И если будут филиалы - функцию запасного можно засчитать как второй контроллер в другом филиале, но... Будет у вас сервер DHCP? А как он будет дублирован? В общем сперва подумайте, сколько конкретно ВАМ надо контроллеров.
С виртуалками есть один нюанс - в домене время должно синхронизоваться, желательно И с внешним источником И внутри. Ставя машины на виртуалке, вы можете забыть снять галку "синхронизация времени", тогда ваша виртуалка станет жить не по времени домена, а по времени гипервизора. С печальным итогом... Еще не додумайтесь оживлять "консервы" - если контролер домена выбыл на ощутимое время из сети (например на месяц) - потом его лучше не возвращать. Он может попортить вам ключи шифрования в домене.
Про линукс забудьте, вам и так проблем на первое время хватит...
4) Характеристики, как я уже писал, пофиг, но если у вас есть DFS и есть несколько серверов с файловым ресурсом - то как минимум не должно случиться переполнения на меньшем по объему диске. А еще есть теневые копии. Стоит под них тоже рассчитывать пространство (например на одном диске в 5ТБ - выделить 1 ТБ, а остальные реплики DFS диски ставить по 4ТБ, но уже без теневых копий).
5) Собственно даже если у вас не будет ни одного сервера на физической машине - ничего страшного в этом нет. Делайте как надо лично вам, рекомендации - просто для сведения.
6) Операционки не имеют значения, но есть такое понятие, как режим контроллера домена - т.е. к первому 2012-му вы сможете потом добавить 2022, но к первому 2022 добавить 2012 не выйдет, если явно не ставить сразу старый режим.
7) Много:

Миграция пользователей - начинайте с молодых и однотипных.

Перемещаемые профили. Раскурите. Очень хорошо потом помогает от воплей ВСЁ ПРОПАЛО! ВСЯ РАБОТА БЫЛА ТОЛЬКО НА РАБОЧЕМ СТОЛЕ! ДИСК СДОХ! ПОЧЕМУ МНЕ КУПИЛИ ДИСК, КОТОРЫЙ ЧЕРЕЗ 8 ЛЕТ СДОХ?! Есть минусы, но там не так всё плохо, и всё настраивается.

Политики безопасности - ВНАЧАЛЕ продумайте, разделяйте и властвуйте. Это ОЧЕНЬ важно.

Ни в коме случае не работайте под админкой администратора домена и не давайте ее пользователям. Организуйте группу локальных админов, которые могут админить только свои ПК. И лучше всего им запретить доступ на всё рабочие станции по сети (от сетевых червей спасёт). А для целей доступа админа по сети - лучше сделать третью группу (например для автоматизированного развертывания ПО).

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

Сетевые диски - сразу разворачивайте через DFS и цепляйте через политики. Не делайте по старинке через "расшаривание".

Резервное копирование данных - рассматривайте все, вообще все негативные сценарии, а не только отказ одного диска в RAID массиве. Это может и полный отказ массива, и вполне легитимное удаление данных пользователем, и работа злоумышленника (оборудованного ГОЛОВНЫМ МОЗГОМ), и шифрование в каникулы, чтоб к выходу с них у вас зашифрованные данные оказались и в резервной копии тоже, и т.д. и т.п.

Удаленка - учтите ограничения программ, типа anydesk и сразу думайте про переход на серверы терминалов. А потом вы поймете, что пользователи ВСЕГДА сливают пароли. И к вам на удаленку полезут злоумышленники с головным мозгом. Поэтому для таких случаев двухфакторная авторизация (без паники, это бесплатно).

Себе админку на удаленке не открывайте в интернет. Только VPN, IPSec, Wireguard и т.п.

Гадящие мессенджеры и яндекс-диски - создают 100500 тыщ мильёнов файлов в профиль пользователя. Убираем из синхронизации с серверной копией сразу.

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

При декларативном подходе (CSS) мы говорим браузеру, что именно сделать, а он уже сам решит, как именно сделать это оптимально для себя и для устройства, на котором он работает. При императивном подходе (JS) мы контролируем каждый шаг и не даём свободы, браузер вынужден делать то, что автор скрипта скажет, даже если ту же самую задачу он может решить лучше и оптимальнее него.

Тут прям все теории заговора придумали с DRM (хотя доля истины в этом тоже есть)

но никому не приходило в голову что видео в некоторых форматах через оверлей отображается, который не попадает в скриншоты и в захват экрана тупо потому что через отдельный механизм видеоподсистемы компа на экране отображается? (и не для целей drm, а просто потому что так устроено)
Я такие удивленные вопросы еще лет 15 на форумах читал, когда drm-ом еще и не пахло (массово), а mpeg-ускорители уже во всех практически видеокартах были

в линуксе это работает в т.ч. потому что там видеоподсистема по другому работает и велика вероятность что ускорение видео тупо не функционирует

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

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

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

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

Получится. А вот и скрипт который делает это автоматически https://github.com/gitpel/letsencrypt-routeros
Можно выкинуть из него лишнее, если он делает больше необходимого

Если бд имеет поддержку json, то общие поля сделать полями таблицы, а добавочную часть положить в виде json в ещё одно поле таблицы.