Puis-je utiliser mon repository git existant avec openshift?

Est-il nécessaire d’avoir go repo uniquement sur openshift? J’ai déjà bitbucket / github git repo et je préférerais y pousser uniquement. Est-ce que je peux simplement m’y accrocher pour qu’Openhift soit averti?

Ou pour simplifier, je ne fais que pousser à github, mais quand je veux me déployer, je fais quelque chose avec openshift?

Je l’ai vérifié mais cela m’a déconcerté: il s’agit de fusionner l’exit et le nouveau (openshift) git?

J’ai l’impression que vous n’êtes pas habitué à utiliser assez de git. Je vous conseille de vous lancer dans la compréhension de la manière de pousser votre code à openshift. Néanmoins, laissez-moi essayer de vous expliquer les étapes à suivre: Comme vous le feriez avec git en général, l’approche à suivre ici consiste à cloner votre autre repo git (par exemple sur bitbucket) sur votre machine locale:

git clone

Votre clone local a alors votre autre repo (bitbucket etc.) comme repo distant. Votre repo distant est stocké avec l’alias “origin” (l’alias par défaut utilisé par git si vous clonez). Vous ajoutez ensuite le référentiel openshift comme distant à votre clone. Vous faites cela tout en utilisant explicitement un alias pour le repository à distance que vous ajoutez – J’utilise “openshift” comme alias ici:

git remote add openshift -f

Pour pouvoir ensuite transférer le code de votre repository git local vers openshift, vous devez d’abord fusionner votre référentiel openshift avec votre clone bitbucket local. Vous faites cela en émettant localement:

git merge openshift/master -s recursive -X ours

Avec cette commande, vous indiquez à git de fusionner la twig principale du référentiel openshift git avec votre référentiel git local. Vous lui dites de fusionner en utilisant la stratégie de fusion récursive et de choisir votre version (“notre”) en cas de conflit.

Une fois la fusion exécutée, vous êtes prêt à pousser votre repository git vers openshift. Vous faites cela en faisant:

git push openshift HEAD

Vous dites à git de pousser votre code local vers la twig HEAD du repo distant appelé “openshift” (l’alias auquel nous avons stocké le référentiel openshift git, quelques paragraphes plus haut).

btw. J’ai écrit un blog jboss tools qui montrait comment utiliser le client openshift-java il y a quelques mois: https://community.jboss.org/wiki/Enable-openshift-ciFullExampleUsingOpenshift-java-client . Vous verrez les étapes ci-dessus dans le dernier paragraphe “Nous y sums presque”.

Je sais que la question a 2 ans et la réponse de @adietisheim a été acceptée. Personnellement, je n’aime pas fusionner le repo openshift dans mon clone local car je ne veux pas mélanger le repo OpenShift dans la twig principale de mon repo public.

En supposant que vous avez ajouté la télécommande en utilisant git remote add openshift , voici ce que je ferais:

Créez une nouvelle twig locale openshift fonction de la twig principale.

 git checkout -b openshift 

Vous pouvez effectuer des openshift sur le programme openshift la twig, telles que les configurations de déploiement de votre application. Ensuite, déplacez la twig actuelle vers le maître correspondant de la référence distante dans le référentiel OpenShift avec l’indicateur -f pour remplacer tout ce qui se trouve dans la twig master distante.

 git push openshift master -f 

Chaque fois que je veux déployer mon application sur OpenShift, je vérifie la twig openshift locale et fusionne la twig principale avec elle, puis forcez la poussée vers OpenShift, mais -f peut ne pas être requirejs pour les prochaines poussées:

 git checkout openshift git merge --no-ff master git push openshift master -f 

De votre dossier de projet, faites

 git remote add backup user@server:/path/to/git/test.git git push backup master 

Vous pouvez lire Pousser à deux origines distantes git à partir d’un référentiel et Changer l’origine git à distance .

Je suis d’accord avec la réponse de @adietisheim: il faut mieux comprendre git avant de déployer avec openshift =)

Maintenant, même si vous comprenez git, il n’est pas forcément évident de déployer votre référentiel existant si votre structure de répertoires ne correspond pas à la structure de répertoires requirejse par openshift et si vous souhaitez conserver votre ancienne structure de répertoires.

Pour cela, j’ai les astuces suivantes:

  • des options distinctes qui dépendent du déploiement dans des fichiers différents. Par exemple, je sépare mes parameters de firebase database d’autres parameters en différents fichiers en tant que:

    • settings_deploy / openshift

    • settings_deploy / localhost

    et puis un lien symbolique vers votre test localhost comme quelque chose comme:

     ln -s settings_deploy/localhost settings_deploy_file 

    Une autre option consiste à détecter l’hôte à l’aide de variables d’environnement:

     if 'OPENSHIFT_APP_NAME' in os.environ: //openshift configurations else: //localhost 

    C’est un peu plus simple car cela vous permet de placer toutes les configs sur un seul fichier. C’est un peu moins général, car si jamais un autre de vos hôtes propose une variable d’environnement OPENSHIFT_APP_NAME (peu probable pour celui-ci), la méthode est interrompue. Quoi qu’il en soit, vous devez toujours séparer clairement ce qui dépend du déploiement et ce qui ne l’est pas.

  • créer un répertoire de déploiement local

  • cloner le modèle openshift initial dans celui-ci

  • créer un script de déploiement qui:

    • tous les liens de votre ancien local existant à leurs emplacements corrects au

      les liens durs sont rapides à créer et utilisent très peu de mémoire

      vous pourriez utiliser quelque chose comme:

      cp -lrf original_repo_dir deploy_repo_dir

    • conservez uniquement le fichier settings_deploy correct dans le référentiel de déploiement:

      cd deploy_repo

      mv settings_deploy/openshift settings_deploy_file

      rm -r settings_deploy

    • force poussée:

      cd deploy_repo

      git push -f origin master

    • nettoyer le repo de déploiement:

      git reset --hard HEAD

      git clean -df

Pour ceux qui s’intéressent au déploiement de django, j’ai un exemple sur mon github , en particulier le script deploy.sh et les projects/elearn du projet qu’il déploie.

Vous devriez pouvoir transférer un référentiel Git existant dans le pipeline des ressources via

 rhc create-app $APPNAME ruby-1.9 --from-code $GIT_LOCATION 

Le référentiel Git distant fournit alors l’application initiale d’OpenShift.

Comme deuxième possibilité, vous pouvez ignorer la création du référentiel OpenSHift Git local via

 rhc create-app $APPNAME ruby-1.9 --no-git 

puis utilisez les étapes décrites ci-dessus pour fusionner le référentiel Git distant d’OpenShift dans votre référentiel Git local.

La réponse de Mohannd est parfaite, mais je voudrais résumer la solution complète, au cas où d’autres en auraient besoin:

Pour utiliser votre repository github en tant que référentiel Openshift, il n’y a pas de solution parfaite maintenant, car Openshfit utilise des hooks git pour déclencher le déploiement ou le redéploiement en fonction de vos commits. Cependant, la manière la plus intelligente serait d’utiliser deux repo (celle de l’openhift et celle de votre github) pour pousser simultanément le code.

Pour ce faire: Ajoutez une télécommande nommée “all” et ajoutez-y 2 URL push.

 git remote add all ssh://23456781234567@yourapp-namespace.rhcloud.com/~/git/yourapp.git git remote set-url openshift-git-repo --push --add ssh://23456781234567@yourapp-namespace.rhcloud.com/~/git/yourapp.git git remote set-url github-repo --push --add git@github.com:youruser/yourapp.git 

Ensuite, définissez la télécommande nommée «all» comme télécommande par défaut:

 git push -u all 

Pour valider et pousser votre code, procédez comme d’habitude: il va pousser sur les 2 télécommandes et déployer sur OpenShift

 git add . git commit -m "my commit" git push 

Et regardez le résultat:

 [master 3fc96b2] my commit 1 file changed, 2 deletions(-) MyLaptop:myapp User$ git push Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 291 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) To git@github.com:User/myapp.git a036a44..3fc96b2 master -> master Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 291 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Stopping PHP 5.4 carsortingdge (Apache+mod_php) remote: Waiting for stop to finish remote: Waiting for stop to finish remote: Building git ref 'master', commit 3fc96b2 remote: Preparing build for deployment remote: Deployment id is 9037d37a remote: Activating deployment remote: Starting PHP 5.4 carsortingdge (Apache+mod_php) remote: Application directory "/" selected as DocumentRoot remote: ------------------------- remote: Git Post-Receive Result: success remote: Activation status: success remote: Deployment completed with status: success To ssh://23456789@myapp-namespace.rhcloud.com/~/git/myapp.git/ a036a44..3fc96b2 master -> master MyLaptop:myapp User$ 

J’espère que cela t’aides

J’ai rencontré des problèmes lors du déploiement d’un référentiel de code préexistant dans Openshift. Dans mon contexte particulier, où j’ai essayé de déployer une application Web tomcat, les fichiers de configuration Openscat de tomcat inclus dans le dossier .openshift étaient essentiels.

Ce qui a été corrigé pour moi a été l’inclusion du dossier .openshift dans mon arbre source existant, ainsi que l’inclusion du profil openshift dans mon fichier maven pom.xml.

Il est fort probable que la même chose se produirait en fusionnant votre référentiel avec le nouveau serveur openshift en amont. Pour moi, c’est le “pourquoi” derrière la phrase suivante dans la grande réponse d’adietisheim:

“Pour pouvoir ensuite pousser le code de votre repository git local vers openshift, vous devez d’abord fusionner votre référentiel openshift avec votre clone bitbucket local.”

Dans mon cas, cette fusion était nécessaire pour obtenir les fichiers de configuration du répertoire .openshift. Cela a pris beaucoup de temps à comprendre pour moi, car pousser sans l’annuaire .openshift continuait à générer et à déployer mon application avec succès. Le seul comportement que j’ai vu était un rapport sur les fichiers jsp manquants, ce qui m’a fait penser que le problème était lié à ma propre configuration web.xml et servlet.

Si vous utilisez github, vous pouvez configurer travis pour effectuer le déploiement chaque fois que vous avez modifié votre repository github

http://docs.travis-ci.com/user/deployment/openshift/

Il y a un moyen de faire ce que vous voulez, c.-à-d. Sauter le repo de Openshift. Ce que vous devez faire est de configurer un jenkins, et de le faire interroger votre propre référentiel.

Il y a un lien ici qui explique comment le configurer à partir de zéro: http://blog.anthavio.net/2014/01/deploy-to-openshift-from-github.html

Si vous utilisez java, il existe une autre approche. Mais même dans cette approche, vous utiliseriez toujours le repository OpenShift git. Le référentiel git fourni par OpenShift est la manière dont vous donnez votre code à OpenShift, votre (vos) déployable (s):

Vous pouvez – au lieu d’engager votre code dans le repository OpenShift git – simplement lui donner votre fichier de guerre. Vous clonez le repository OpenShift git sur votre machine locale. Vous créez ensuite une guerre à partir de votre source d’application et placez cette guerre dans le dossier de déploiements de votre référentiel OpenShift git (clone). Vous ajoutez ensuite, validez et poussez votre clone local vers OpenShift. Une fois le push exécuté avec succès, JBoss AS7 choisira votre guerre et la déploiera.

PRENEZ FACILEMENT!

étape 1: créer une application. Avec votre méthode préférée (à partir de gitRepository, Openshift, etc.). si vous utilisez la console metod
étape 2: rhc git-clone nameApp
étape 3: rhc app-configure nameApp --auto-deploy
étape 4: PROFITEZ!