sys.argv
, но внутри не используете, поэтому у вас ничего не делающие s = s
.#вместо def main(argv):
def main(s,n,k,a_ext):
a = [] #копируем содержимое из списка во внутренний
for i in range(n):
a.append(a_ext[i])
Making(a, k, 0, s, "%d=" % s)
return 0
...
if __name__ == "__main__":
main(s,n,k,a)
FROM image-with-onbuild
и никак иначе. Т.о. задача корректна только в случае, если создается дочерний образ от сборочно-запускающего. service-couple-name: this
, а другую service-couple-name: that
, и выставить в сервисах разные deploy.placement.preferences
по этому лэйблу, то планировщик будет пытаться поднимать их на соответствующих нодах пока они есть. Если все померли, а потом какие-то поднялись, то балансировку сервисов надо делать руками/скриптами/самописными внешними сервисами. -p 3658:3658/udp \
sudo nsenter -n -t $(docker inspect -f '{{.State.Pid}}' wg-easy) iptables -t nat -A PREROUTING -d $(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' wg-easy) -p udp --dport 3658 -j DNAT --to-dest 10.8.0.2:3658
sudo nsenter -n -t $(docker inspect -f '{{.State.Pid}}' wg-easy) iptables -t filter -A INPUT -p udp -d 10.8.0.2 --dport 3658 -j ACCEPT
Для примера, предположим, что есть (сферический в вакууме) CRUD сервис ... Предположим, что точная оценка не требуется. Даже погрешность в несколько раз будет приемлемой.Сервисов в вакууме не бывает, разный код и внешние зависимости будут влиять по-разному на использование ресурсов с разбегом в несколько порядков.
Например, для оценки latency существуют подобные таблицыПутаете физику с лирикой. В приведённой вами таблице значения вырастают из физических и технических ограничений.