littleguga: Софтовый VPN между серверами, выглядящий, как просто ещё один сетевой интерфейс, по которому все сервера доступны между собой, словно если бы они находились в одной локальной сети.
ТёмнаяМатерия: 2) Общепринятые практики, исторически формирующиеся между проектами.
Вряд ли существует прямо единый документ с типами файлов, обязывающий исполнение. Типы файлов именуют так, как все привыкли их читать, работая над другими проектами.
Если проект маленький, конфиг и лог в нём всего один, конечно же можно сделать и:
config.txt
log_20160514.txt
Но есть проекты, в которых разные конфиги разделены друг от друга, а логи разделены по тематике/подсистемам/сабдоменам.
Представьте эту кучу txt-файлов в одной папке. Чтобы отличать файлы друг от друга, вам всё равно придётся добавлять в имя что-то вроде "log_20160514_git.txt" или "config_subsystem.txt". Зачем вот так нагромождать имя файла, если характер файла (его тип) можно просто вынести за точку, где его сразу будет видно?
Вы не обязаны следовать этой практике, но при передаче проекта кому-то ещё, или при росте архитектуры проекта, следующему разработчику это может быть непривычно/неудобно. А так, хоть все файлы проекта в txt заведите. =)
3) Почему нет? Рабочий процесс некоторых разработчиков таков, что они открывают файлы дабл-кликом. ОС определяет, через какую программу ей открыть файл, исходя из типа за точкой.
conf может открываться в IDE, log - в просмотрщике логов.
spotifi: Я тоже считаю, что рисков в связи с этим мало. Должно многое совпасть.
Но технически сделать это возможно.
Просто если других задач для такого внутреннего туннеля не будет, и у проекта есть готовность на период миграции слегка рискнуть приватными данными пользователей, авторизующихся в сервисе, то городить туннель не обязательно.
Я бы перестраховался, но лишь потому, что я смогу это быстро настроить. =)
Артём Сахаров: Понимаю. Сложно выполнять задачи, когда инструменты для выполнения тебе не предоставляют, игнорируя такие преимущества, как меньшие простои.
Будет хорошей идеей дополнить _всеми_ подробностями о ситуации и ограничениях пост с вопросом, чтобы отвечающим не бегать по комментариям.
Если пост хоть чем-нибудь понравился, можно спасибкнуть. Мотивейшн! =)
Maxim: Форвард приведёт к ассоциации одного домена с другим, а для поисковика это означает склейку проблемного сайта с новым. Ведь вопрос был поставлен в ключе "как начать всё с нуля". =)
Артём Сахаров: Вопрос был о способах массового применения обновлений.
В этом контексте, Windows-сервера справятся с этой задачей самостоятельно, без дополнительного ПО.
Ваш вопрос на самом деле можно перефразировать: он не про применение обновлений, а про то, как можно удалённо мониторить их успешность применения и, в случае ошибки, как удалённо исправлять. А также как обосновать это работодателю, если вы хотите научиться делать это без поездок на работу.
> у меня нет доступа к GPO
В принципе, он не нужен. Можно один раз настроить применение на конкретное время вручную на каждом сервере.
> необходимо контролировать процесс выполнения обновления
WSUS в отчётах визуально показывает степень применения конкретных обновлений на конкретный пул серверов.
Если какие-то обновления не установились - их можно пнуть вручную. Насколько я понял, именно сейчас Вы этим и занимаетесь, но делаете это редко, из-за чего не видите смысла в еженедельных поездках.
Что Вы понимаете под применением обновлений?
Фоновую установку патчей безопасности, или принудительный рестарт серверов после каждого обновления? Другими словами, вы каждые выходные перезагружаете все сервера?
