Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 48
алиас делаешь сразу с подключение к нужному айпи с нормальным именем)
тоже хороший вариант, только не только в консоли это нужно)
Например, для перекидывания файликов через sftp использую гуишное приложение
алиас делаешь сразу с подключение к нужному айпи с нормальным именем)
Когда хостов не 50 или там 100 а ТЫСЯЧИ, я перестаю запоминать даже алиасы)
Хоть как их не именуй "нормальными именами".
В файле hosts у меня список доменных имён из поп-ап окон. Всё они резолвятся как 127.0.0.1
Звучит интересно, а про какие поп-ап окна речь и для чего это?
Чтобы заблочить запросы на эти сервера, кэп ) А то мало ли что уйдёт на telemetry.microsoft.com. Поэтому каждый порядочный джентльмен пишет в hosts: 127.0.0.1 telemetry.microsoft.com
Тут писали про поп-ап окна. Для меня это окна, которые вылетают в лицо в случайных местах. Вот интересно что имелось ввиду
...а потом жалуются почему микрософт принимает такие уе...жасные решения. Да потому что нормальные пользователи выпали из метрик и статистик
За это мнение мне конечно напихают, но как еще понять сколько пользователей переносят кнопку пуск наверх экрана 1%, 2%, 10%? Никак, только статистически, только через телеметрию.
Беда в том, что по телеметрии (даже если бы она отсылалась) принимать никакие решения нельзя. Решения можно принимать только в прямом диалоге с пользователями и через оценки. А не так что "я хозяин продукта, творю что хочу". Хотя у Microsoft еще с 90-х сценарий всех изменений один и тот же - сделать плохо, получить тонну хейта, а потом вернуть как было. Тут и видимость постоянных изменений, и счастье юзеров не уменьшается. Профит.
Рекламные окна, которые выскакивают при открытии, например, странички на сайте Rutor.
а зачем они на 127.0.0.1 ходят ? логичнее тогда 0.0.0.0
Самодельный adblock? Но... зачем?
"о, сколько вам открытий чудных готовит..." мир DNS
Так и не понял за всю свою жизнь, как построить отказоустойчевый DNS.
Вот вам 2 самые частые причины отказа:
1) Все оплаты делаются с одноразовых счетов, и это приводит к провалам в сроках оплаты. Информационная гигиена не позволяет привязывать актуальный счёт.
2) Отказ в обслуживании. DNS провайдеры отжимают домены, санкции запрещают переводы, конторы закрываются.
Выходит, что DNS или шифрование HTTPS - просто точка отказа по административной плоскости.
Зачем сюда это писать??? И кто это сюда пропускает.
Странный пост, странное решение
Если не знаешь свою инфраструктуру, а серверов для подключения действительно много, то и в доменных именах будет путаница в итоге
Вы писали что для подключений используете "гуи", так в большинстве приложений есть возможность нейминга подключений, по этому не совсем ясно для чего прописывать доменные имена
Было бы смешно увидеть как человек с таким же успехом забывает какие он домены навыдумывал и лезет в хост каждый раз что бы вспомнить что там
Но хорошо, что вы сами придумали проблему, что бы самому не решить - очевидно растет эффективный менеджер хД
Ну тут я с Вами не соглашусь.
Если не знаешь свою инфраструктуру, а серверов для подключения действительно много, то и в доменных именах будет путаница в итоге
Знать свою инфраструктуру не то же самое, что помнить наизусть все свои хосты. Как по мне, помнить все свои хосты в большинстве случаев будет мусорной информацией (здорово, если Вы их помните).
Путаница в доменных именах будет только если вы даёте плохой нейминг, либо не обновляете его по мере внесения изменений.
Да, могут быть ситуации, когда проще использовать 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
Может потому, что не только для ssh может хост понадобиться?
Человечество придумало для таких вещей как минимум ~ /. ssh/config
Создал, прописал, RDP не работает. Браузер тоже не открывает по имени. Это я к тому что не SSH'ем единым полон мир. Есть еще windows и браузеры.
Нам вот админы не могут(не хотят) зону *.rnd.company.ru делигировать. В итоге, это очень весело настраивать 50 web-based железок(камеры, smart-коммуты, snr-erd) по IP-адресам. Единственный способ или поднять свой DNS и жонглировать корпоративный-свой или hosts
Очень вредная и по бОльшей части не верная статья. Скоро начнем читать статьи о том, как включить в 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 со стороны как клиента, так и со стороны сервера
А можете скорректировать в чём я не прав? Я не стал её описывать подробно и упоминать кэши. Какие-нибудь пару пунктов, где я не верно говорю про принцип?
Если это нужно только мне, то я не вижу смысла заводить себе систему DNS. Ибо нет разницы, буду я менять его у себя локально или на dns сервере, который ещё поддерживать нужно будет.
Да, только то, что нравится лично вам и что является плохими практиками, вы тащите на хабр в статью. И разница есть. У вас «локально работает» только на конкретном экземпляре вашего компьютера, dns же будет работать даже если вам потребуется что то сделать в отпуске с кофеварки.
Возможно, я просто рассуждаю, этот сценарий и ваша убежденность в удобстве своего подхода родились из того, что эти сервера не являются вашей основной работой и вам не нужно их поддерживать на постоянной основе.
про ~/.ssh/config никто не вспомнил?
Ну, это такой смешной файл, куда пишется хост, юзер и т.д., чтобы потом ssh myserver - и готово?
Тут, возможно, набегут знающие люди и скажут “дык этож начальная школа”.
Да-да. Ведь именно в начальной школе еще не знают, что подчеркивание в доменном имени это недопустимый символ (сюрприз?).
Ждём статью "Как перестать путаться в доменных именах серверов"
Шутки-шутками, а я бы почитал про кейсы нейминга. Потому что когда вы работаете в company.ru все просто.. вроде бы.
server1.company.ru, server2.company... а потом их становится 10 и хочется переименовать в server01...(хотя можно было бы сразу)
Потом появляется филиал...уже хочется чего-то вроде server01.filial.company.ru...
и виртуалки... vm01.server01.filial.company.ru
Появляется второй филиал... как его неймит? 02 или по географии?
А что делать если мы поставляем системы на разные предприятия? system.vm.server.company.ru или vm.system.company.ru?
А еще очень весело неймить какие-ндб русские аббревиатуры систем типа СКУ ШС ЭЧ
Офигеть если честно, что такое требует статьи с иллюстрациями и объемным текстом. Я для себя навайбкодил утилитку на golang, которая умеет читать каталог с yaml конфигами которые выглядят примерно так (очень упрощённо):
commands:
- my_command:
flags: # тут описываются флаги, которые потом можно использовать как переменные
tasks: # тут некая цепочка операций, с передачей результата друг другу
- http: # запрушиваем данные из какого-то API
register: my_var1
- file: # читем файл
register: var2
- template: # обрабатываем данные с помощью gotemplete
# с кастомными функциями, такими как могучий jq
register: tmlp_result
- ui_select: # интерактивно выбираем из списка
register: ui_result
- command: ssh {{ ui_result }}Да. Это намеренно напоминает Ansible.
Пользуемся так:
invi <command> [flags] [query]В результате я запрашиваю списки хостов
invi px my-vm # запрос VM в Proxmox
invi inv my-search-query # запрос из инвентарника Ansible
invi nb --my-dc dataline my-host # запрашиваем в нетбоксеТе я просто описываю в конфиге цепочку действий, которые мне позволяют сохранить результат в файл или выполнить команду или сделать очередной запрос в API с интерактивным выбором из списка. Это очень удобно. На все ушло возможно меньше времени чем на написание данного поста :-/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как перестать путаться в IP-адресах серверов