Порекомендуете другу?
— Какая вероятность, что вы порекомендуете Docker Desktop другу или коллеге?
— 2 из 10. Если бы у меня был хотя бы один из них, тогда, возможно...
раскрыть ветку (22)
Если есть хотя бы какой-то опыт с линуксом (поднять виртуалку, установить что-то, задеплоить приложение, скрипт написать), то ничего сложного в освоении докера нет, имхо.
раскрыть ветку (2)
раскрыть ветку (1)
тогда проблем быть не должно.
- открываете хендбук
- ставите докер, опираясь на него
- (опционально) ставите докер-композ. //мне лично он зашел, ибо удобно
-- (опционально) пишете композ-файл // вы в yml-формате конфига пишете какие контейнеры нужны, что в них открывать, что прокидывать и тд. если надо, конечно.
- ...
- все работает. вы великолепны
а всякие тонкие настройки, свармы, оркестрирование - можно изучить по ходу надобности.
раскрыть ветку (18)
раскрыть ветку (17)
раскрыть ветку (5)
Host не подходит, мне нужно изолированное сетевое окружение до которого должен быть доступ снаружи
раскрыть ветку (4)
зачем? ты пробрасываешь нужный порт, при обращении к хосту по этому порту он обращается в контейнер.
причем можно пробрасывать порт N в M (ну, допустим 80:23423 и т.п.)
раскрыть ветку (3)
раскрыть ветку (2)
раскрыть ветку (1)
Проблема еще в том, что сам контейнер должен знать свой реальный IP по которому до него можно достучаться, и берет он его НЕ из конфига
Прошу прощения, но тут глупость написана. Зачем "сервису" который запускается в контейнере белый IP да ещё и по dhcp? В принципе задача решаемая, но как по мне относится к "специальной олимпиаде". За весь мой опыт этого ни разу не потребовалось. Если уж и приспичило такое, то проще на хост где крутится докер выделить пул адресов и разруливать на уровне операционной системы.
раскрыть ветку (10)
Ну, я могу один сценарий представить. Платёжные системы с большой вероятностью будут требовать белый айпишник, и пускать только с него. При том часто именно отдельный белый айпишник надо. Скажем, лет 5 назад Skrill требовали гарантию, что для связи с ними используется отдельный айпишник, в других сервисах не замаранный. Хрен знает, нафига им это, но требовали.
раскрыть ветку (8)
А у вас точно есть опыт работы с докером? Мне кажется что вы не слышали о пробросе портов из контейнера.
раскрыть ветку (7)
раскрыть ветку (6)
странно, конечно, юзать РТП, учитывая что его списали лет 15 назад, но если у тебя реализация через UDP, не забудь при пробросе указать /udp. Все это, конечно, есть в доках к докеру.
раскрыть ветку (3)
Спешу тебя огорчить но RTP до сих пор активно используют для IP телефонии в том числе в новомодном WebRTC, и проброс тут не спасает, сервис сам динамически открывает порты и сообщает удаленной стороне свой ВНЕШНИЙ адресс. STUN и TURN к сожалению у нас не поддерживаются
раскрыть ветку (2)
блин, может я не совсем понимаю задачу. Но, смотри, запущенный докер контейнер это же не сам сервис, а окружение. можно сделать чтобы ip-адрес внутри контейнера был точно такой же как у хоста. То есть если сам хост имеет "белый" ip, то внутри контейнера при --net=host будет он же.
Далее, для своего сервиса ты должен знать в каком диапазоне портов он работает, ибо не может софтина юзать вообще все порты рандомно. Ну там врятли в рандомно юзаемый порт попадет 80/443/8080/etc. Этот диапазон портов ты и открываешь. В итоге получается что у тебя есть хост, с белым ip, есть докер контейнер запущенный на этом же хосте, и он тоже думает что у него такой же ip, и если будет комуто сообщать свой адрес, то даст этот ip и порт. и когда клиент снаружи по этому адресу:порту будет ломиться на хост комп, докер редиректнет все пакеты внутрь контейнера.
Проще говоря, если ты можешь настроить окружение и сервис на хост компе без докера, то с докером ты тоже это сможешь сделать. разница только в том что в случае использования докера у тебя изолированное окружение, и через хост можно следить за ее состоянием и прочим барахлом, при желании. Так же внутри докер окружения ты можешь понаставить всяких библиотек и утилит которые необходимы твоему сервису, в то время как на хосте их не будет. И в итоге на условно "чистом" хосте у тебя есть легко переносимое на другой хост настроенное окружение, с нужными версиями либ и пакетов именно для твоего сервиса.
раскрыть ветку (1)
Должно быть изолированное сетевое окружение, и нельзя занимать порты хост машины, такие требования инфраструктуры
А вы уверены в том что докер подходит для данного софта? Я думаю с такими требованиями софта ему будет лучше на отдельной виртуалке.
раскрыть ветку (1)
Ну вот в этом и проблема, раньше очень долго жили на реальном железе, т.к. очень высокие требования к real-time операциям, планировщик виртуальных машин постоянно вставляет палки в колеса, в контейнерах с планировщиком все хорошо, но сеть нормально настроить немного геморойно.
IT-юмор
5.6K поста52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору