Вопрос в тему. Есть несколько Docker-хостов, хотелось бы сделать между ними общую директорию, которая будет монтироваться в контейнеры, т.к. я заранее не знаю, на каком хосте будет поднят контейнер. Как лучше поступить в этом случае? NFS? GlusterFS? DRBD? Ceph? Есть ли well-known способы обхода проблемы с блокировками?

Смешались в кучу люди, кони... Ну, ты ведь сам знаешь, что приведённые тобой в пример инструменты решают разные задачи, не так ли? Видеть в одном предложении NFS, DRBD и ceph странно.

Смешались в кучу люди, кони... Ну, ты ведь сам знаешь, что приведённые тобой в пример инструменты решают разные задачи, не так ли? Видеть в одном предложении NFS, DRBD и ceph странно.

Конечно, знаю. Но я знаю, что есть люди, применявшие все перечисленные мною технологии для этого вопроса, с разной степенью успешности, я всё же изучал вопрос перед тем как прийти сюда. А вообще это не несло конкретной смысловой нагрузки, просто спискота.

Конечно, знаю. Но я знаю, что есть люди, применявшие все перечисленные мною технологии для этого вопроса, с разной степенью успешности, я всё же изучал вопрос перед тем как прийти сюда. А вообще это не несло конкретной смысловой нагрузки, просто спискота.

Тогда, в принципе, ты также должен знать, что твоя задача легко абстрагируется от эхотега и сводится к "нужно иметь одно хранилище, доступное с Х хостов". Остаётся решить, где хранилище должно быть (на одном хосте, на нескольких, на всех), и выбор инструмента для реализации станет практически очевидным.

@nirfse, это не тебе вообще было. Смотри, на что стоит reply. Тьфу ты, обиделся, снёс все свои сообщения и ливнул. Теперь чятик придётся чистить...

Тогда, в принципе, ты также должен знать, что твоя задача легко абстрагируется от эхотега и сводится к "нужно иметь одно хранилище, доступное с Х хостов". Остаётся решить, где хранилище должно быть (на одном хосте, на нескольких, на всех), и выбор инструмента для реализации станет практически очевидным.

Должен. Более того, к подобным выводам я пришёл и сам, не первый день в IT. Но это всё не более чем логические измышления, я же не зря пришёл именно в сообщество Docker с этим вопросом, вполне возможно, что есть какие-то подводние камни, связанные конкретно с Docker, гуру которого я пока не являюсь, или у кого-то был опыт внедрения подобного решения. Явно же не самый редкий кейс.

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

Если нужно запустить Postfix в каком-то контейнере (ради контейнера) - используйте что-то другое.

Если надо пиздануть просто, а не что-то конкретное, просто пизданите

Если надо пиздануть просто, а не что-то конкретное, просто пизданите

Я вам просто сообщил о том, что postfix в Docker не запускают. Его можно запустить в других контейнерах - например, LXC.

Ну или прикручивать к Docker supervisord

Но это уже совсем другая история

Благодарю. Эти рекомендации выданы и многим ранее, и там же уже даны пояснения.

Привет, а кто может подсказать про storage в AWS ECS? Нужно один volume к нескольким заданиям подцепить

смартконтракты

перфокарты ?

ребята, подскажите, как нужно настроить так, чтоб у docker образов был доступ к файлам, но при этом не нужно им выставлять sudo chmod -R 777

Тут есть пример как это делать через ACL https://github.com/wodby/docker4drupal/blob/master/docs/permissions.md - очень удобно

коллеги, подскажите пжлста как это вылечить: Pulling docker image git.domain.ru/domain/core ... ERROR: Preparation failed: Error response from daemon: Get https://git.domain.ru/v2/domain/core/manifests/latest: unauthorized: HTTP Basic: Access denied причем это в гитлабе запускается пайплайн, который должен запустить докер, а я не пойму где-что сломалось, и как это чинить

коллеги, подскажите пжлста как это вылечить: Pulling docker image git.domain.ru/domain/core ... ERROR: Preparation failed: Error response from daemon: Get https://git.domain.ru/v2/domain/core/manifests/latest: unauthorized: HTTP Basic: Access denied причем это в гитлабе запускается пайплайн, который должен запустить докер, а я не пойму где-что сломалось, и как это чинить

По моему там просто просрочен сертификат, не?

может быть, но не понимаю где и как проверить. подскажи пжлста, я пока новый в докере)

Ну и если по ссылке сходить все же - то аккаунт отключён одменом

Никак) что это за контейнер вообще?

по ссылке сертификат самоподписанный, сроком до 2030г а текст на странице: {"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"domain/core","Action":"pull"}]}]}

в контейнере ансибл должен запускаться.

как понять что сломалось?

с учетом того, что это гит должен запускать, я вообще плыву ?

Написано же русским языком, по твоей ссылке требуется http авторизация. Либо логин/пароль с которым ты ломишься неправильный, либо тебе туда над стучатся по git с ключами, а не https.

так ключ не мог протухнуть. еще на прошлой неделе работало. Сейчас нет. Если например виновен ключ, то как это проверить? потому что в .gitlab-ci.yml написано только image: git.domain.ru/domain/core

сам руками дергал ссылку? https://git.domain.ru/v2/domain/core/manifests/latest которая

конечно. вот описание по ссылке сертификат самоподписанный, сроком до 2030г а текст на странице: {"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"domain/core","Action":"pull"}]}]}

конечно. вот описание по ссылке сертификат самоподписанный, сроком до 2030г а текст на странице: {"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"domain/core","Action":"pull"}]}]}

Те что и требовалось доказать, оно хочет авторизации, а ты ее не прописал где-то. Либо что-то обновилось на выходных, либо кто-то в этой части поменял настройки. Ищи

Вы говорите абсолютно точно. Но к моему сожалению абсолютно бесплезно. Авторизация была прописана, мне достался этот монст, и я пытаюсь понять как оно должно работать. Так как сейчас конструкция не работает, то я и пытаюсь понять где и что надо прописать, или убедится что прописано.

Вы говорите абсолютно точно. Но к моему сожалению абсолютно бесплезно. Авторизация была прописана, мне достался этот монст, и я пытаюсь понять как оно должно работать. Так как сейчас конструкция не работает, то я и пытаюсь понять где и что надо прописать, или убедится что прописано.

На чем поднят этот репозиторий? Гитлаб?

гитлаб + гитлаб-ci

который запускает докер, в котором ансибл

Поищи группу гитлаба, спроси там у людей как они авторизацию эту прописывают. либо в ru_devops сходи, там может кто есть щас. Проверь что руками у тебя работает конструкция docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN myregistry.com

ну понятно что свое подставь

должно быть Login Succeeded

Возможно у тебя эта волчанка https://gitlab.com/gitlab-org/gitlab-ce/issues/20185 - проверь там по каментам версию

понял, попробую покурить в эту сторону. О результате сообщу

А как понять под кем оно логинится должно? в конфигах нашел: auth: token: realm: http://git.domain.ru/jwt/auth service: container_registry issuer: omnibus-gitlab-issuer rootcertbundle: /var/opt/gitlab/registry/gitlab-registry.crt

парни киньте ссылкой на php комьюнити

А как понять под кем оно логинится должно? в конфигах нашел: auth: token: realm: http://git.domain.ru/jwt/auth service: container_registry issuer: omnibus-gitlab-issuer rootcertbundle: /var/opt/gitlab/registry/gitlab-registry.crt

смотрите в секретных переменных гитлаба DOCKER_AUTH_CONFIG - с помощью нее CI авторизуется

эти переменные в проекте или есть на группу проектов переменные?

нашел переменные REGISTRY_PASS REGISTRY_USER и DEPLOY_KEY при попытке написать docker login -u <REGISTRY_USER> -p <REGISTRY_PASS> git.domain.ru/group/project говорит про сертификат.

Error response from daemon: Get https://git.domain.ru/v1/users/: x509: certificate signed by unknown authority

но это локальный реестр, и сертификат там самоподписанный до 2030

ну вот самоподписанный и бреет

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

а если я сертификат сегодня ни чем не отличается от пятничного, то должен быть вариант логина в реестр с игнорированием сертиката, или пояснением "доверять"

DOCKER_OPTS="--insecure-registry myregistrydomain.com:5000"

https://gitlab.com/gitlab-org/gitlab-ce/issues/18239

эти переменные в проекте или есть на группу проектов переменные?

может быть и так и так. переменные на проекте перекрывают на группе.

на проекте нет переменных. На группе есть, но при попытке воспользоваться - ругается опять на сертификат

вот подсказали на DOCKER_OPTS посмотреть. Изучаю как им воспользоваться

это надо трогать раннер

в конфигах раннера это должно быть указано?

ага

как-то грустно у меня cat /etc/gitlab-runner/config.toml concurrent = 1 check_interval = 0

раннер пускает докер, докер внутри исполняет скрипты gitlab-ci, в которых стоит image: ну и далее все подцепит

ERROR: S client not available

если конечно не шелл

не шелл. С таким конфигом как у меня, оно вообще должно было работать?)

не шелл. С таким конфигом как у меня, оно вообще должно было работать?)

у вас нет гитлабовского раннера... либо вы его не там ищите :)

вот же он

Чудно. Возможно это какой-то дефолтный. У меня каждый runner имеет свою секцию в файлике... добавьте новый раннер попробуйте.

у меня их уже три!

у меня их уже три!

не важно сколько их - важно глянуть их настройки. А вы их показать не можете :)

настройки в файле /etc/gitlab-runner/config.toml ? я его показал весь

настройки в файле /etc/gitlab-runner/config.toml ? я его показал весь

https://docs.gitlab.com/runner/configuration/advanced-configuration.html

нашел. есть машина где живет гит есть машина где живет докер на гите конфиг я уже показывал. На докере он выглядит как у вас

concurrent = 1 check_interval = 0 [[runners]] name = "dev" url = "http://git.domain.ru" token = "7c732097c9936aeeedf4e528850879" executor = "docker" [runners.docker] tls_verify = false image = "ubuntu:16.04" privileged = false disable_cache = false volumes = ["/cache"] shm_size = 0 [runners.cache]

это на машине с докером

Тут есть пример как это делать через ACL https://github.com/wodby/docker4drupal/blob/master/docs/permissions.md - очень удобно

спасибо, сохранил. Дома попробую.

возможно я близок к разгадке: пр попытке запустить docker login git.domain.ru предлагается ввести пароль старого админа.

возможно я близок к разгадке: пр попытке запустить docker login git.domain.ru предлагается ввести пароль старого админа.

вы имеете в виду "логин" ? Посмотрите $HOME/.docker/ - там лежит файлик настроек

да, логин и пароль.

root@dev:~/.docker# cat config.json { "auths": { "git.domain.ru": { "auth": "YmF1a2luOnYxdnI0FlUw==" }, "registry.domain.ru": { "auth": "cmVwb3VzZXI6cmVb3Bhc3M5" } }

привет) если есть 1 нода в swarm-mode режиме, какой вариант вам кажется более логичным - через docker service create или через docker stack deploy? в чём реально разница между этими вариантами, какой более современной? (с оглядкой на интеграцию с Kubernetes в будущем может быть)

то есть если сервис всего 1, имеет ли смысл его запускать декларативно описывая через конфиг или лучше просто командой?

возможно я близок к разгадке: пр попытке запустить docker login git.domain.ru предлагается ввести пароль старого админа.

старый админ имел токен уровня api

вы заблокировали его учетку - авторизация пошла по бороде

это обычная мина замедленного действия)

сходите и получите новый токен https://git.domain.ru/profile/personal_access_tokens для api

я завел независимый акк на отдел и токен сложил в ENV