закидывал, да

попробуй просто ssh-keygen -t rsa

тоже самое

попробуй просто ssh-keygen -t rsa

сгенерил, сунул публичную часть в ключи Gitlab, ответ идентичный

посмотрел в authorized_keys на сервере, ключ поменялся

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

мда... похоже я прокачаюсь на эту тему, пока разберусь ))

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

где?

на сервере?

да

ну, в самом контейнере везде пользователь git

-rw------- 1 git git 1577 Aug 13 16:53 authorized_keys -rw-r--r-- 1 git git 0 Aug 13 16:53 authorized_keys.lock

Пользователь может быть git, но его UID может отличаться от пользователя git на другой системе.

(вроде)

почему он при отправке ключа rsa_id никакую ошибку не выдает... вот что странно. Хоть бы ругнулся как-то

ребятки у гитлаба свой ssh сервер

с мультиплексацией соедиенений.

и завязан он на свои механизмы

надо искать простую причину со стороны клиента

файл нет тот. права не те

вот и я о том, что сервер ковырять бесполезно

вольюм не праивльный

какой еще волюм?

Если я правильно понял, то все ломается на этапе попытке подписать какой-то пакет ключом rsa_id и его отправить.. Не понимаю механизма. (

Ладно, это вопрос уже админский скорее, а не докера, пойду в Девопс

*прибрал простыню.

Ты не в тот devops пошёл. Мы же все помним, что ламповый devops это @ru_devops ?

Спасибо

А это я из ру девопса перепостил

чъёрт, придётся бота писать, который будет не бот и будет историю сообщений смотреть

чатовые библиотеки конечно надо чем-то организовывать. групповые теги - без них сложно

но для это надо читать историю, а бот апи не умеет

Потому что это оказалось крайне удобным. Приходит такой новичок: "А что мне почитать?" А ты ему такой: "Пятая книжка сверху в Shared Media!" Не все же сходу набегают в чатик только чтобы задать используя набор мудных круто звучащих слов полную чушь, показывающую, что спрашивающий даже общего представления об области не получил. Некоторые вот даже книжками интересуются.

Да, книжки добрая тема. Про докер, правда, все что я видел просто разжеввывают документацию

статей много хороших есть

У докера просто дока норм

ну скажем так, толковых

Докер просто ещё слишком часто меняется чтобы

Докер просто ещё слишком часто меняется чтобы

это не докер

В смысле? Докер тоже. Я вон его краем уха пользую и то вижу "ключи туда, ключи сюда". Не считая развития ядра, Go и прочего

Кстати, как в докере посмотреть иерархию локального хранилища

Эт что?

docker history id?

хз

Ну слои можно

ну я там каких-нибудь докеров накачал, каких-то набилдил, там уже черт ногу сломит а я всё забыл

docker images

docker images

а иерархию кто кого?

-а

а иерархию кто кого?

была раньше docker tree но ее выпилили

А смысл?

ну как

тебе сваливается вопрос типа вон там наш сервис крутится там в него нада кой чо положить ла ла ла

ты такой "а посмотрю как я прям по имиджу, насколько слоен он"

точне скока там ФРОМов

и ихрен те )

ОСБС ))) https://github.com/spotify/docker-gc

ERROR: S client not available

ребят, кто-нибудь rabbitmq разворачивал в docker?

почему я не могу после выполнения этих команд зайти по на 15672 порт через браузер? >docker run -d -p 5672:5672 -p 15672:15672 --name rabbitmq rabbitmq >docker start rabbitmq

ребят, кто-нибудь rabbitmq разворачивал в docker?

Да. А какую версию ставишь? Нужно с суффиксом -management rabbitmq:3-management

сказывается глубокая ночь

я не могу понять. вот есть контейнер mysql из стандартного репо. поднялся. где он хранит данные? что за магия? я хочу волюм явно указать, а он без волюма мне всё записывает, и ведь даже сохраняет

/me конечно под алкоголем немножк, но может я просто что-то не так делаю?

там можно волюм же указать, а иначе он в контейнер прям и гадит

там можно волюм же указать, а иначе он в контейнер прям и гадит

+1

нет, он таки в контейнер гадить сам не может, ибо контейнер ro

но он нагадил в контейнер db. а я таки хочу волюм подмонтировать в папку, что я и сделал в итоге )

всё ок

нет, он таки в контейнер гадить сам не может, ибо контейнер ro

он или может или нет. как кстати ты сделал контейнер ro?

Папочки объявленные вольюмом он сам сделает

И сделает их rw

Через inspect можно глянуть куда он гадит

Ты не в тот devops пошёл. Мы же все помним, что ламповый devops это @ru_devops ?

А я тогда не пошел еще, убежал отдыхать. Вот сейчас буду рулить.

Всем кто ранее интересовался настройкой http-proxy для докер энвайромента будет любопытна эта #article (Только тем у кого нет болезни фатального недостатка в анамнезе) #link https://technologyconversations.com/2016/08/01/integrating-proxy-with-docker-swarm-tour-around-docker-1-12-series/

он или может или нет. как кстати ты сделал контейнер ro?

У меня что-то типа билд машины. Дойду до компа скину конфигурацию. Брал где-то с просторов гитхаба

Через inspect можно глянуть куда он гадит

Кстати спасибо, разобрался с волюмами, осталось понять как их мигрировать правильно

Кстати спасибо, разобрался с волюмами, осталось понять как их мигрировать правильно

--volumes-from

ну это не миграция конечно, но позволяет получить данные в другом контейнере

Документация и гитхаб. Великолепно

Добрый день. Я новичок в докере. У меня многоконтейнерное приложение. Я использую compose. Как мне это приложение деплоить? Есть смысл засунуть compose в еще один докер-контейнер? Это нормальная практика?

А чего именно вы этим планируете добиться?

А чего именно вы этим планируете добиться?

Я просто не совсем понимаю, как приготовить докер к продакшну правильно. Я полагал, что я могу завернуть compose в контейнер, запушить его. А на продакшне только пуллить его.

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

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

Предположим, у меня публичное многоконтейнерное приложение и я хочу его распространять. И хочу, чтобы оно было простым в деплое. Какие варианты вижу я: 1. Распространять docker-compose.yml. Проблема — вместе с ним будет тянуться весь код из репозитория. А он же не нужен (compose берёт образы из hub). 2. Делать отдельный репозиторий под один единственный docker-compose.yml и поддерживать его. 3. Распространять готовый контейнер в хабе. Внутри контейнера compose. В compose другие контейнеры. 4. Что-то ещё, что я упускаю.

В случае публичного многоконтейнерого имхо действительно будет проще распространять образом. Но тогда встает вопрос безопасности - если просто делать пулл + ран с пробросом докер-сокета получается что машина отдается на откуп недоверенному коду из этихваших.

Я бы предпочел, все таки, вариант 2 как предоставляющий большую иллюзию контролируемости