Как развернуть jenkins и jenkins-slave, если у них несоответствующие серии?

Примечание: я запускаю это на 3 доверенных виртуальных машинах Ubuntu на моем ноутбуке с OS X через VMWare Fusion.

Я новичок в джуджу, и у меня возникли проблемы с настройкой Дженкинса-раба. У меня есть загрузочная машина и 2 другие машины. Jenkins (master) успешно установлен на компьютере 1. Когда я пытаюсь развернуть jenkins-salve, я получаю сообщение об ошибке:

juju deploy -n 1 jenkins-slave
cannot assign unit "jenkins-slave/0" to new machine: use "juju add-machine ssh:[user@]<host>" to provision machines

Я также попробовал:

juju remove-service jenkins-slave
juju deploy jenkins-slave --to 2
Added charm "cs:precise/jenkins-slave-7" to the environment.
ERROR cannot assign unit "jenkins-slave/0" to machine 2: series does not match

Это не имеет смысла, так как перед тем, как попытаться развернуть jenkins, я добавил две машины:

juju add-machine ssh:machine1
juju add-machine ssh:machine2

оба успешно закончены. Вот мой вывод статуса

juju status
environment: manual
machines:
"0":
agent-state: started
agent-version: 1.20.14
dns-name: thebat
instance-id: 'manual:'
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=979M
state-server-member-status: has-vote
"1":
agent-state: started
agent-version: 1.20.14
dns-name: elemental
instance-id: manual:elemental
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=979M
"2":
agent-state: started
agent-version: 1.20.14
dns-name: terrifying
instance-id: manual:terrifying
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=979M
services:
jenkins:
charm: cs:trusty/jenkins-2
exposed: false
units:
  jenkins/0:
    agent-state: started
    agent-version: 1.20.14
    machine: "1"
    open-ports:
    - 8080/tcp
    public-address: elemental
jenkins-slave:
charm: cs:precise/jenkins-slave-7
exposed: false
units:
  jenkins-slave/0:
    agent-state: pending

2 ответа

Ответ довольно прост, но очень маловероятен. Брелок для jenkins-slave - это точный брелок, который означает, что его можно установить только на точную Ubuntu VM.

Хотя это кажется очевидным только после целого дня с Джуджу, я считаю, что это серьезная проблема с этим инструментом. Chef / Puppet и т. Д. Не зависят от вкуса, так почему же зависит версия аромата дзюю? На мой взгляд, это серьезный недостаток планирования.

Вы используете провайдера вручную, что означает, что вы должны вручную управлять сериями брэндов и сопоставлять их с сериями, развернутыми на устройстве. Если бы вы использовали, например, локального провайдера (документация содержит предопределенный образ Vagrant, который был протестирован для работы на OS X), Juju автоматически управлял бы распределением модулей - включая серию - для вас, чтобы вы не столкнулись с этим вопрос.

Серия, определенная для брелка, - это версия Ubuntu, на которой брелок был проверен и с которым, как известно, работает. Вполне возможно, что брелок будет работать с более новыми сериями, и во многих случаях один и тот же брелок представлен для обеих серий. (Также было некоторое обсуждение поддержки многосерийных талисманов, где поддерживаемые серии определены в талисмане metadata.yaml.)

Если вы найдете брелок, который доступен только для определенной серии, но вы действительно хотите запустить его на другой серии (с оговоркой, что он может работать неправильно), вы всегда можете разветвлять брелок из Launchpad в структуру локальной директории: <series>/<charm-name> и развернуть его с помощью juju deploy local:<series>/<charm-name>, (Это тот же процесс, который автор брелка использовал бы для создания брелка, поддерживающего новую серию. Если вы сделаете это и сможете использовать брелок для работы, то, безусловно, сопровождающий брелок будет благодарен за то, что вы отправили свои изменения, чтобы Очарование в поддержку новой серии.)

Обратите внимание, что ограничение серии применимо только к машине, на которой развернут этот брелок. Пока два брелка поддерживают один и тот же интерфейс, они могут быть связаны и работать вместе, даже если они работают в разных сериях.

Другие вопросы по тегам