Comments 33
алиас делаешь сразу с подключение к нужному айпи с нормальным именем)
тоже хороший вариант, только не только в консоли это нужно)
Например, для перекидывания файликов через sftp использую гуишное приложение
алиас делаешь сразу с подключение к нужному айпи с нормальным именем)
Когда хостов не 50 или там 100 а ТЫСЯЧИ, я перестаю запоминать даже алиасы)
Хоть как их не именуй "нормальными именами".
В файле hosts у меня список доменных имён из поп-ап окон. Всё они резолвятся как 127.0.0.1
Звучит интересно, а про какие поп-ап окна речь и для чего это?
а зачем они на 127.0.0.1 ходят ? логичнее тогда 0.0.0.0
"о, сколько вам открытий чудных готовит..." мир DNS
Зачем сюда это писать??? И кто это сюда пропускает.
Странный пост, странное решение
Если не знаешь свою инфраструктуру, а серверов для подключения действительно много, то и в доменных именах будет путаница в итоге
Вы писали что для подключений используете "гуи", так в большинстве приложений есть возможность нейминга подключений, по этому не совсем ясно для чего прописывать доменные имена
Было бы смешно увидеть как человек с таким же успехом забывает какие он домены навыдумывал и лезет в хост каждый раз что бы вспомнить что там
Но хорошо, что вы сами придумали проблему, что бы самому не решить - очевидно растет эффективный менеджер хД
Ну тут я с Вами не соглашусь.
Если не знаешь свою инфраструктуру, а серверов для подключения действительно много, то и в доменных именах будет путаница в итоге
Знать свою инфраструктуру не то же самое, что помнить наизусть все свои хосты. Как по мне, помнить все свои хосты в большинстве случаев будет мусорной информацией (здорово, если Вы их помните).
Путаница в доменных именах будет только если вы даёте плохой нейминг, либо не обновляете его по мере внесения изменений.
Да, могут быть ситуации, когда проще использовать ip, так в этом случае и стоит его использовать. Никто не запрещает пользоваться двумя вариантами. Есть например реплика сет базы данных состоящего из primary-реплики, secondary-реплики и арбитра. Так почему бы их не назвать так (да, primary и secondary могут поменяться. Они для этого и нужны), но они настраиваются с предпочтениями под конкретную задачу, так почему бы не использовать human-readable конструкции.
Вы писали что для подключений используете "гуи", так в большинстве приложений есть возможность нейминга подключений, по этому не совсем ясно для чего прописывать доменные имена
Я использую несколько вариантов. SSH консоль, SFTP чаще всего гуи. То что в гуи есть нейминг это верно, и я использую его. Но так во всех тулзах, которые Вы используете нужно будет пойти и поменять ip-адрес, а так у вас одна точка принятия решения.
Было бы смешно увидеть как человек с таким же успехом забывает какие он домены навыдумывал и лезет в хост каждый раз что бы вспомнить что там
Это уже вопрос плохо нейминга и самоорганизации.
Вы тут пишете про нейминг и тд, и вот вроде это правильная мысль, только решение вы максимально убогое предложили. Даже ssh config будет не идеальным решением, потому что вы можете пересесть на другой компьютер где не будет вашего hosts и возможно config. Используйте нормально dns. А еще лучше используйте ansible, нечего руками по серверам ползать, что бы потом не удивляться откуда конфигурационный дрифт появился.
У меня как раз не было цели разворачивать DNS. Это настройка только моей рабочей машины, так чтобы мне было удобно работать.
То что я могу пересесть на другой компьютер, тоже в полне ожидаемое и возможно событие. Но речь в статье именно о том как сделать это для себя (без привлечения других людей и доп. инфраструктуры).
Про ssh config я уже увидел в нескольких комментария рекомендацию, спасибо.
За рекомендацию ansible тоже спасибо. Задачи на серверах менять конфигурацию достаточно редкая, но думаю полезно знать о тулзе.
DNS это не так сложно. Хостинги DNS (AWS, Yandex Cloud) стоят не так дорого. К примеру в Yandex Cloud это примерно 44 рубля за зону(домен) в месяц и 38 рублей за 1 млн запросов к записям. Одного домена как правило достаточно.
Ansible же это не только про менять, редко или часто, конфигурацию на сервере. Это история про идемпотентность, то есть если вы 1 раз настроили какую то роль в ansible и далее простым действием раскатали эту роль на N серверов и вы будете уверены в том, что на все сервера конфигурация встало одинаково.
Вы же сами писали про большое кол-во серверов, имхо на масштабах, когда вы уже не помните, где и что у вас на серверах, жить без нормальных инструментов - это очень сильно не любить себя и свое время.
DNS это не так сложно. Хостинги DNS (AWS, Yandex Cloud) стоят не так дорого. К примеру в Yandex Cloud это примерно 44 рубля за зону(домен) в месяц и 38 рублей за 1 млн запросов к записям. Одного домена как правило достаточно.
Тут дело не в деньгах или сложности. Я не думаю что мне будет сложно поднять или настроить(скорее всего что-то поизучать всё равно придётся). Тут вопрос только профита от этого. Если это нужно только мне, то зачем усложнять.
Может получится как типичная история "программист тратит несколько часов на автоматизацию задачи, которую можно сделать вручную за 5 минут" :)
Да, это правильно. Но нужно ли? Получу ли я то преимущество ради которого делаю это? А если нет разницы, то мой ответ тут только один :) Когда понадобится, тогда и сделаю)
Это как выбирать монолит или микросервисы)
Тут палка о двух концах: с одной стороны, иногда решить задачу вручную действительно быстрее и проще, но если задача достаточно нечастая - в следующий раз придётся вспоминать, "чего я тут такое делаль-то?"
Правда, для этого ещё скрипты придумали: один раз пусть даже долго пишешь - потом запускаешь не вникая и не вспоминая чё -как.
в etc ещё лезть в правами администратора. напишите лучше ssh_config он простой. Host myserver HostName 192.168.1.10 . перенаправлет подключение к myserver на 192.168.1.10
Спасибо, посмотрю
люто плюсую. Причём можно указывать масками различные настройки. Например у меня задана маска *.companyname чтобы прописать рабочий ключ, не указывая его к каждому. Также удобно сразу прописывать порт, если он нестандартный - голова не болит помнить, какой там порт используется. Единственное о чём приходится помнить - имя пользователя.
Да когда уже вы в покое несчастный hosts оставите? Человечество придумало для таких вещей как минимум ~ /. ssh/config
Очень вредная и по бОльшей части не верная статья. Скоро начнем читать статьи о том, как включить в 220В сетевой штунр не перепутав со шнуром от USB-C
1. Не стоит править hosts для резолвинга имен (да, слово резолвинг, если уж транслитерацию используем, обозначает "преобразование" доменного имени в IP адрес) так как при изменении ip адреса будет проблематично проводить диагностику неисправности сей. Для подобного существуют, например, .ssh/config файл, где можно прибить к имени и ip и порты и ключи и остальное для ssh. Но для подобного, если у вас инфраструктура больше пары хостов и прям уже надо не забыть ip адрес, достаточно развернуть внутренний dns и не мучаться, ибо снова - смена адреса = проблемы с вопросом - что это не работает ничего.
2. Вы совершенно не верно описали принцип работы DNS со стороны как клиента, так и со стороны сервера. Слышали, но почему-то погуглить или чатгпт спросить - не спросили. Если решите пробел в знаниях убрать, то гуглить стоит про dns forwarding и dns recursion.
upd.
Да, про PTR в курсе, если кто мне напомнит)
Но для подобного, если у вас инфраструктура больше пары хостов и прям уже надо не забыть ip адрес, достаточно развернуть внутренний dns и не мучаться, ибо снова - смена адреса = проблемы с вопросом - что это не работает ничего.
Если это нужно только мне, то я не вижу смысла заводить себе систему DNS. Ибо нет разницы, буду я менять его у себя локально или на dns сервере, который ещё поддерживать нужно будет.
Про отладку. В целом если знаешь как настроена своя рабочая машина, то проверка коннекта по прямому ip-адресу у меня будет стоять первым пунктом.
Но в любом случае, спасибо за совет.
Вы совершенно не верно описали принцип работы DNS со стороны как клиента, так и со стороны сервера
А можете скорректировать в чём я не прав? Я не стал её описывать подробно и упоминать кэши. Какие-нибудь пару пунктов, где я не верно говорю про принцип?
про ~/.ssh/config никто не вспомнил?
Ну, это такой смешной файл, куда пишется хост, юзер и т.д., чтобы потом ssh myserver - и готово?
Тут, возможно, набегут знающие люди и скажут “дык этож начальная школа”.
Да-да. Ведь именно в начальной школе еще не знают, что подчеркивание в доменном имени это недопустимый символ (сюрприз?).
Как перестать путаться в IP-адресах серверов