Сервер Spring Cloud Config, использующий ключ SSH для Git и работающий в Docker

Question

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

Я пытаюсь получить частный git-репозиторий на BitBucket для работы с Spring Boot Config Server с использованием ключей развертывания и запуска его в Docker. Я сталкиваюсь со многими проблемами.

1. Как на самом деле настроить, используя файлы application.yml.

Я не могу понять, где я должен поместить информацию SSH. Все учебники, кажется, для https.

2. Как предоставить закрытый ключ для конфигурации. Для Dev синтаксис для inline в YML - это боль. Для производства вы должны предоставить его через переменную окружения, что является еще одной синтаксической задачей.

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

3. Как заставить Docker-контейнер доверять ключу хоста без этой надоедливой подсказки "ты доверяешь этому парню"?

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

Answer 1

Первая часть - это конфигурация. Вы хотите игнорировать стандартный закрытый ключ и использовать его в качестве переменной среды. (SSH_KEY). Кроме того, git-репо - это EV (GIT_URL), но вы можете жестко закодировать, если хотите.

spring:
  cloud:
    config:
      server:
        git:
          uri:  ${GIT_URL}
          ignore-local-ssh-settings: true
          private-key: ${SSH_KEY}

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

private-key: |
                    -----BEGIN RSA PRIVATE KEY-----
                    MIIEpAIBAAKCAQEAszmCR06LVHk/kNYV6LoYgEfHlK4rp75sCsRJ7rdAbWNED+yB
                    bneOm5gue0LGIhT7iTP9D7aN6bKVHv1SBconCA7Pa2NMA9epcMT5ecJc8ndpZOFn
                    iqM77jmMMPvj8EIC06w5oK5zoYwpGotYQFHllf8M+20HtW2fZdPYAYwLcVdmc5tI
                    vLoS+10qw5D3X9zrwk2Cbt37Iqnz1cHOQq+g7sxgVgt18aIKKeg0JslaGqSlWMoT
                    ICUMHj89E4BMHj8ND8otSXHL+VhN+ghd7w1MpckxLWBsNs1+G1FuiJEVAtRq/j+8
                    SOilxgifvI1LqpZ5kO01XFlmkcuN4NMT03qpcwIDAQABAoIBAB5oQGk2sz7mv1kk
                    aV0tzaBeDUd1cWSpUw1UljKRFrY4ZEDLYH5MfH57iE9TWehIZRC3KFU1JMikitZS
                    JktjK9IbKSfQFgKE4XOHh8gXqMteZRw/feCwpydYzic1ZUvK903QZ4qSbn3XGNYv
                    FA79lhUny50Qt4EZkzSkh35js0FMSR9VmyXENxN6IgXUZyoaNAATr44Vkd488BY2
                    7PvdOniemo8/8p4Ij0Aq9Q7rOtm77ZXjyFRX5mDTi2ndSllMEhVcWXHSii+ukbvF
                    117Ns+8M7VWroNfRzI+Ilm/Xz/ePOLlNoYcY0h5+QM9vMPTX9Cpl5WofgOMK1sKd
                    mSdI4ukCgYEA12kcu0aDyIrEPHcyaT9izSFply0Uon2QKS9EQn6cr83vaEGViamh
                    f5q1coYouGnsLfbgKolEMKsYtbmJvInPFDCdc2x0Fmc207Wp1OECsN+HwElEXkrs
                    uPDpGQgs5odjN5Grue9837920oG3UBBdVDAKly2dTOcvoWW+88seFSUCgYEA1P7f
                    p78HDMQ8zTy5+3Rd4+lmJjPsY618XxSQ80j8Elrhi/DyTMA0XGc5c3cKRPmSj+JD
                    GN34WQbw7JO2mKM7YJs+tkSBeTKce8F3cZQy1jy3LNHCtfXylOxmxOFKynV5h2b/
                    jno+pGdmAPK5yvnGASd2eujtzt+AL07XiD2LnLcCgYEAsFRz131WfP/SuShdlLf1
                    WbODKuQVIxojuwLdHo1kF6k805v0G/dGoxzycOgPRz41vj57q3Yn4qr8FC3n6PTq
                    FT3idUyPDpO41r67Ye469KxWBHo1Q/aTJqTWOs5tatvixOcyqoa3MrUZQCI8+4YZ
                    z8Nvt+b3/66zV6vhDtHzMx0CgYAvWW2M0+mUS/ecRHivzqGkrdkYewh87C8uz9qd
                    SsdGqU9kla63oy7Ar+3Unkz5ImYTeGAkIgw4dlOOtBOugPMNOdXKHRaPQ9IHrO2J
                    oUFf4OVzoDnhy4ge1SLPd6nxsgXPNPVwzfopABdr9Ima9sWusgAjuK5NA+ByI9vE
                    HLJxpwKBgQCTM938cdx457ag1hS6EaEKyqljS1/B8ozptB4cy3h0hzw0crNmW84/
                    1Lt9MJmeR4FrWitQkkVLZL3SrYzrP2i+uDd4wVVD5epvnGP/Bk6g05/eB9LgDRx/
                    EeBgS282jUBkXZ6WpzqHCcku3Avs3ajzsC1WaEYx0tCiBxSkiJlaLQ==
                    -----END RSA PRIVATE KEY-----

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

$ pem=$( cat path_to_key )
$ docker run -e "SSH_KEY=$pem" configserver

На этом этапе вы должны позаботиться о приложении. Теперь все, что вам нужно, - это преодолеть проблему ssh host not trust. Для этого добавьте эти строки в ваш Dockerfile. Замените "bitbucket.org" любым хостом, который вы хотите. Эти команды создают каталог конфигурации ssh, фиксируют права доступа, а затем создают и заполняют файл knownhosts.

RUN mkdir -p /root/.ssh
RUN chmod 700 /root/.ssh
RUN ssh-keyscan bitbucket.org > /root/.ssh/known_hosts

Answer 2

Я хотел добавить еще один поворот в этом вопросе, который, мы надеемся, избавил бы от необходимости возиться с SSH-ключами в файле YAML (или в переменных env), что обычно является плохой идеей.

Это вращается вокруг файла конфигурации SSH, поэтому, если приложение не имеет к нему доступа или не может быть изменено, это не сработает (но я не могу вспомнить ни одной реальной ситуации, в которой это применимо, включая развертывание в облаке): либо шаблоны AWS Cloudformation, либо Kubernetes ConfigMaps предоставят полезные обходные пути).

Проблема связана с (по большей части) ограничением (довольно необъяснимым) невозможности указать файл закрытого ключа в свойствах приложения Spring Config.

В вашем ~/.ssh/config файл, вы можете добавить следующее:

Host git-config
    HostName github.myserver.example.com
    User someone
    IdentityFile /path/to/private_key

(Мне нужно подключиться к частному серверу GitHub Enterprise, и пользователь, связанный с ключом SSH, отличается от того, под которым работает сервер приложений: это работает просто отлично; если это не так, просто используйте github.com для HostNameи опустить User)

Тогда вместо использования фактического URI GitHub, что-то вроде:

[e-mail]:my-team/config-properties-demo.git

вы заменяете git-config для хозяина:

spring:
  cloud:
    config:
      server:
        git:
          uri: git@git-config:my-team/config-properties-demo.git
          strictHostKeyChecking: false

Это действительно немного громоздко, но относительно легко автоматизировать. Наиболее предпочтительным вариантом для Spring Config было бы добавить еще один параметр, который указывает на материал закрытого ключа:

spring:
  cloud:
    config:
      server:
        git:
          uri: [e-mail]:my-team/config-properties-demo.git
          user: someone
          private_key_file: /path/to/private_key
          strictHostKeyChecking: false

Я полагаю, что это один из разделов "запросов на улучшение"...

Answer 3

Прошу прощения за некро, но это результат № 1 в Google (из SO) при поиске способов выполнения SSH-аутентификации с Git-репозиториями, когда сервер конфигурации развернут в среде с эфемерной файловой системой - и я считаю, что нашел способ сделать это. Ниже суть того, что я сейчас делаю, чтобы это произошло для моего клиента.

https://gist.github.com/hanserya/43b00162741fa3022481301db60e8acd

Это определенно гадкий утенок, но он функционален и должен служить надежной опорой для всех, кто в этом нуждается. Благодаря этой реализации вы сможете подключить том к контейнеру, на котором работает сервер конфигурации. Затем просто сконфигурируйте среду для использования тома в качестве каталога SSH с ключом конфигурации spring.cloud.config.server.git.sshLocation через любой носитель, который лучше всего подходит для вас (переменные env, bootstrap.yml и т. Д.)

Удачного кодирования!