2017-08-25 6 views
6

J'essaie de migrer d'OpenShift 2 à OpenShift 3. J'ai créé une nouvelle application sur OpenShift 3 mais j'ai du mal à cloner mon dépôt git privé BitBucket . (Je n'ai eu aucun problème avec OpenShift 2).OpenShift 3: impossible de cloner un dépôt BitBucket privé

J'ai essayé de définir des secrets (SSH ou Basic Authentication) dans Build/Advanced Options mais sans chance.

Voici le message d'erreur:

Cloning "[email protected]:(myusername)/(myrepository).git" ... error: 
build error: Host key verification failed. fatal: Could not read from 
remote repository. Please make sure you have the correct access rights 
and the repository exists. 
+1

dites que vous que vous utilisez un référentiel BitBucket privé? Si oui, quelles mesures avez-vous prises pour enregistrer une clé SSH de dépôt dans BitBucket, créer le secret '' sshauth'', autoriser le compte de service '' builder'' à accéder au secret, puis configurer votre build pour l'utiliser dépôt? –

+0

C'est un dépôt privé oui. J'ai défini la clé SSH BitBucket dans le code source secret – zov

+1

Comme déjà demandé, pouvez-vous lister les étapes que vous avez effectuées? Avez-vous utilisé '' ssh-keygen'' pour créer une nouvelle clé SSH de référentiel? Avez-vous enregistré la partie publique de la clé en tant que clé d'accès sur le référentiel privé sur BitBucket? Avez-vous créé un secret dans OpenShift en utilisant '' oc secrets new-sshauth''? Avez-vous autorisé le '' builder'' à utiliser le secret en exécutant '' oc secret link''? Comment avez-vous alors modifié la configuration de construction pour utiliser le secret source? Ou avez-vous essayé de tout configurer via la console Web? Un peu plus de détails vous aidera à comprendre ce que vous avez peut-être manqué. –

Répondre

9

Les étapes si vous travaillez à partir de la ligne de commande sont les suivantes:

1) Créer une nouvelle paire de clés SSH pour une utilisation avec le référentiel. Cela ne peut pas avoir de phrase secrète.

ssh-keygen -C "openshift-source-builder/[email protected]" -f repo-at-bitbucket -N '' 

Cela va générer des fichiers:

repo-at-bitbucket 
repo-at-bitbucket.pub 

étant les principaux dossiers publics et privés.

2) Aller à > Paramètres clés d'accès pour le dépôt sur BitBucket, sélectionnez Ajouter une clé et dans la fenêtre pop-up entrez le nom de la clé openshift-source-builder et coller dans le contenu du fichier de clé publique. Dans ce cas, repo-at-bitbucket.pub. Confirmez la création en cliquant sur Ajoutez la clé dans la fenêtre contextuelle.

3) Créer un secret OpenShift pour la clé en exécutant:

oc secrets new-sshauth repo-at-bitbucket --ssh-privatekey=repo-at-bitbucket 

4) permettre l'accès au secret du compte de service builder.

oc secrets link builder repo-at-bitbucket 

5) Afin que OpenShift connaît le secret est pour ce dépôt Git privée spécifique et utilise automatiquement, annoter le secret avec l'URI SSH pour le référentiel.

oc annotate secret/repo-at-bitbucket \ 
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.org/yourusername/private-repo.git' 

Très important ici est la forme de l'URI. Dans l'interface Web de BitBucket, il s'affichera comme suit:

[email protected]:yourusername/private-repo.git 

Ne l'utilisez pas. Vous devez utiliser le formulaire SSH de l'URI ici.

6) Nous pouvons ensuite déployer l'application à partir du référentiel privé Git.

oc new-app [email protected]:yourusername/private-repo.git --name mysite 

Bon à utiliser [email protected]:yourusername/private-repo.git ici, ou pourrait aussi utiliser la forme SSH de l'URI.

Vous pouvez également faire tout cela à partir de la console Web. Important si vous créez le secret en tant qu'étape distincte dans la console Web pour lier le compte de service builder lors de cette opération. Si vous créez le secret source lors du déploiement, il liera automatiquement le compte de service builder.

Notez que si l'instance OpenShift a un pare-feu entre elle et BitBucket et que les connexions SSH sont bloquées, cela ne fonctionnera pas. Dans ce cas, vous devez utiliser un jeton d'accès personnel (mot de passe d'application) via une connexion SSH à l'aide de l'authentification de base HTTP.


Ces détails sont maintenant beaucoup mieux expliqué par la série de blog commençant par: