Doker: skorzystaj z prywatnego repozytorium GitHub

Question

Próbuję uruchomić kontener, który ujawni usługę golang z pakietu, który mam na prywatnym repozytorium GitHub.

Ponieważ pracuję z GCE, moim obrazem początkowym jest google/debian: wheezy.

Po zainstalowaniu wszystkich wymaganych dependancies i narzędzi, Używam

RUN go get github.com/<my_org>/<my_package> 

gdzie pakiet jest prywatnym repo.

Dodałem moje klucze SSH GitHub aby umożliwić klonowanie z prywatnego repo do pliku Döcker:

ADD priv/id_rsa /root/.ssh/id_rsa 
ADD priv/id_rsa.pub /root/.ssh/id_rsa.pub 

Wciąż otrzymuję błąd podczas idź proces, gdy Go próbował sklonować repo :

# cd .; git clone https://github.com/<my_org>/<my_package> /gopath/src/github.com/<my_org>/<my_package> 
Cloning into '/gopath/src/github.com/<my_org>/<my_package>'... 
fatal: could not read Username for 'https://github.com': No such device or address 
package github.com/<my_org>/<my_package>: exit status 128 

Aby debugować problemy z Dockerfile, używam:

RUN ssh-keyscan -t rsa github.com 2>&1 >> /root/.ssh/known_hosts 

A to mówi mi, że są pewne problemy. Wygląda na to, że sprawdzanie poprawności klucza prywatnego jest OK, ale coś dziwnego dzieje się z kluczem publicznym. To jest kompletna ssh-keyscan wynik:

OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013 
Pseudo-terminal will not be allocated because stdin is not a terminal. 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: /etc/ssh/ssh_config line 19: Applying options for * 
debug1: Connecting to github.com [192.30.252.129] port 22. 
debug1: Connection established. 
debug1: permanently_set_uid: 0/0 
debug1: identity file /root/.ssh/id_rsa type 1 
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 
debug1: identity file /root/.ssh/id_rsa-cert type -1 
debug1: identity file /root/.ssh/id_dsa type -1 
debug1: identity file /root/.ssh/id_dsa-cert type -1 
debug1: identity file /root/.ssh/id_ecdsa type -1 
debug1: identity file /root/.ssh/id_ecdsa-cert type -1 
debug1: Remote protocol version 2.0, remote software version libssh-0.6.0 
debug1: no match: libssh-0.6.0 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: server->client aes128-ctr hmac-sha1 none 
debug1: kex: client->server aes128-ctr hmac-sha1 none 
debug1: sending SSH2_MSG_KEX_ECDH_INIT 
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY 
debug1: Server host key: RSA 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48 
debug1: Host 'github.com' is known and matches the RSA host key. 
debug1: Found key in /root/.ssh/known_hosts:1 
Warning: Permanently added the RSA host key for IP address '192.30.252.129' to the list of known hosts. 
debug1: ssh_rsa_verify: signature correct 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug1: SSH2_MSG_NEWKEYS received 
debug1: Roaming not allowed by server 
debug1: SSH2_MSG_SERVICE_REQUEST sent 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug1: Authentications that can continue: publickey 
debug1: Next authentication method: publickey 
debug1: Offering RSA public key: /root/.ssh/id_rsa 
debug1: Server accepts key: pkalg ssh-rsa blen 279 
debug1: key_parse_private_pem: PEM_read_PrivateKey failed 
debug1: read PEM private key done: type <unknown> 
debug1: read_passphrase: can't open /dev/tty: No such device or address 
debug1: Trying private key: /root/.ssh/id_dsa 
debug1: Trying private key: /root/.ssh/id_ecdsa 
debug1: No more authentication methods to try. 
Permission denied (publickey). 

Próbowałem chmod 600 i chmod 700 na klawiszach priv/publiczny, to nie pomogło.

Jakieś wskazówki? Czy ktokolwiek, kto odniósł sukces, pobiera te pobrania z prywatnych repozytoriów debian z dockera?

Answer 1

Wyjaśniałem to po trochę hackowania. Nie jest to idealne rozwiązanie, ponieważ polega na instalowaniu SSH i budowaniu klucza prywatnego w kontenerze. Ten przykład jest oparty na oficjalnym Docker golang image (Debian Wheezy):

Główna różnica do twojego przykładu jest taka, że ​​potrzebujesz polecenia git config, aby wymusić ssh zamiast domyślnego https.

FROM golang 

RUN apt-get update && apt-get install -y ca-certificates git-core ssh 

ADD keys/my_key_rsa /root/.ssh/id_rsa 
RUN chmod 700 /root/.ssh/id_rsa 
RUN echo "Host github.com\n\tStrictHostKeyChecking no\n" >> /root/.ssh/config 
RUN git config --global url.ssh://git@github.com/.insteadOf https://github.com/ 

ADD . /go/src/github.com/myaccount/myprivaterepo 

RUN go get github.com/myaccount/myprivaterepo 
RUN go install github.com/myaccount/myprivaterepo 

Answer 2

go get próbuje użyć https, całkowicie ignorując ssh.

Będziesz musiał skonfigurować ~/.netrc:

ADD priv/.netrc /root/.netrc 

Gdzie netrc wygląda następująco:

machine github.com login github-username password github-password 

ref:

• https://stackoverflow.com/a/13724351/145587

Answer 3

Rozwijając OneOfOne za ~/.netrc odpowiedzi, to co robię z Jenkins w systemie Linux:

FROM golang:1.6 

ARG GITHUB_USER=$GITHUB_USER 
ARG GITHUB_PASS=$GITHUB_PASS 

# Copy local package files to the container's workspace. 
ADD . /go/src/github.com/my-org/my-project 
WORKDIR /go/src/github.com/my-org/my-project/ 

# Build application inside the container. 
RUN echo "machine github.com\n\tlogin $GITHUB_USER\n\tpassword $GITHUB_PASS" >> ~/.netrc && \ 
    go get github.com/tools/godep && \ 
    go get github.com/onsi/ginkgo/ginkgo && \ 
    godep restore && \ 
    ginkgo -r --randomizeAllSpecs --randomizeSuites --failOnPending && \ 
    godep go install && \ 
    rm -f ~/.netrc 

ENTRYPOINT /go/bin/my-project 

EXPOSE 8080 

Komenda doker build jest:

docker build \ 
    --build-arg GITHUB_USER=xxxxx \ 
    --build-arg GITHUB_PASS=yyyyy \ 
    -t my-project . 

Dwa ARG dyrektyw map --build-arg s więc docker może ich używać w pliku Dockerfile.

Pierwsza i ostatnia linia RUN tworzą i usuwają ~/.netrc.

W Jenkinsach używam tych samych poleceń z polecenia git w poleceniu budowania.

W tej strategii hasło nie jest powtarzane podczas procesu budowania dockera i nie jest zapisywane na żadnej warstwie obrazu dokowanego. Należy również pamiętać, że wyniki testu gingko są drukowane na konsoli podczas kompilacji.