Nous avons le client Git disponible chez Kinsta pour que vous puissiez faire du SSH et retirer votre propre dépôt Git depuis Github, Gitlab, Bitbucket, ou tout autre. L’accès SSH est disponible sur tous les plans d’hébergement de Kinsta.

Si vous débutez, assurez-vous de lire notre guide sur git vs Github.

Cependant, nous n’avons pas encore lancé la fonction qui permet de déployer automatiquement git push kinsta my_site. Cette partie est à venir. Mais vous pouvez toujours utiliser facilement Git chez Kinsta, il suffit de suivre les instructions ci-dessous.

Comment utiliser Git

Vous pouvez créer un script de déploiement en quelques minutes qui va faire du SSH dans votre conteneur Google Cloud Linux et faire apparaître la dernière version de votre dépôt. Les détails de votre SSH pour votre site Kinsta se trouvent sur la page « Info » de votre site.

Commande de terminal SSH dans MyKinsta.

Commande de terminal SSH dans MyKinsta.

ssh my_site@1.2.3.4 -p PORT "cd /www/my_site/public && git pull"

Une autre façon de procéder est d’utiliser WP Pusher. Beaucoup de nos clients l’utilisent et cela le rend super facile, car vous n’avez pas besoin de savoir comment utiliser Git ou SSH.

Austin a également un excellent tutoriel sur la façon de mettre en place un déploiement automatique de Git avec Kinsta en utilisant SSH.

Parmi les autres alternatives, citons Beanstalk et DeployBot. Sinon, vous pouvez suivre les instructions plus détaillées de Git ci-dessous.

Cloner un dépôt

Pour cloner un dépôt :

git clone https://github.com/USER/REPO.git

Lorsque vous utilisez Git pour des dépôts privés, vous utilisez votre identifiant et votre mot de passe GitHub qui sont transmis au serveur.

git clone https://username:password@github.com/USER/REPO.git

Si l’authentification à deux facteurs est activée, un jeton OAuth doit être utilisé à la place de vos informations standard. Suivez les instructions suivantes pour créer un jeton OAuth.

Pour cloner un dépôt qui a activé 2FA :

git clone https://TOKEN@github.com/USER/REPO.git

Dépôt privé

S’il s’agit d’un dépôt privé, il faut ajouter des informations à la liste :

Tirer

ssh my_site@1.2.3.4 -p PORT "cd /www/my_site/public && git pull https://username:password@github.com/USER/REPO"

Repo privé avec 2FA

Si l’authentification à deux facteurs est activée, un jeton OAuth doit être utilisé à la place de vos justificatifs d’identité standard. Suivez ces instructions pour créer un jeton OAuth. Pour déployer une prise en pension dont la fonction 2FA est activée :

Récupérer (pull)

ssh my_site@1.2.3.4 -p PORT "cd /www/my_site/public && git pull https://TOKEN@github.com/USER/REPO"

Si la récupération git ci-dessus ne contient pas les identifiants et le chemin HTTPS, il tentera de regarder localement (plutôt que sur le dépôt hébergé) et affichera le message : « Tout est à jour ».

Gérer les conflits trouvés

Si vous modifiez quelque chose à distance, les commandes de déploiement ci-dessus seront annulées en raison des conflits trouvés. Que devez-vous faire alors ? Cela dépend de celui que vous voulez traiter comme « King ». Dans l’exemple ci-dessous, nous allons traiter le dépôt Git comme « King » et oublier les conflits.

Récupérer de force

Avertissement juste. Ce qui suit remplace les changements qui existent à distance avec ce qui se trouve dans le dépôt Git.

ssh my_site@1.2.3.4 -p PORT "cd /www/MY_SITE/public && git fetch https://TOKEN@github.com/USER/REPO.git && git reset –hard kinsta/mysite"

Si vous avez des questions concernant l’utilisation de Git chez Kinsta, notre service d’assistance sera heureux de vous aider une fois que vous serez opérationnel.

Comment se déployer automatiquement vers Kinsta avec GitLab CI/CD (Avancé)

Pour les utilisateurs plus avancés, GitLab CI/CD (intégration continue/livraison continue) peut être utilisé pour pousser automatiquement les changements de code vers votre site Kinsta chaque fois qu’un nouveau commit est poussé vers la branche concernée. Cette méthode vous permet de pousser continuellement du code vers votre environnement en production sur Kinsta sans écraser la base de données MySQL de WordPress.

Créer un site Kinsta (facultatif)

Pour les besoins de ce tutoriel, nous allons créer un nouveau site vide sur Kinsta, et nous installerons WordPress ultérieurement. Si vous avez déjà un site Kinsta, vous pouvez toujours suivre ce tutoriel.

Dans MyKinsta, allez à votre page « Sites » et cliquez sur Ajouter un site dans le coin supérieur droit. Sélectionnez l’option « Ne pas installer WordPress », donnez un nom à votre site, sélectionnez un emplacement et cliquez sur le bouton Ajouter un site pour terminer le processus de création du site.

Créer un site vide dans MyKinsta.

Créer un site vide dans MyKinsta.

Créer un projet GitLab

Pour commencer, rendez-vous sur GitLab et cliquez sur Créer un projet » pour créer un nouveau dépôt pour votre site Kinsta.

Créer un projet dans GitLab.

Créer un projet dans GitLab.

Sélectionnez l’option Projet vierge, et remplissez les champs « Nom du projet » et « Slug du projet ».

Créez un projet vierge dans GitLab.

Créez un projet vierge dans GitLab.

Pour l’option « Niveau de visibilité », nous recommandons de rendre le dépôt privé. Comme ce dépôt peut contenir du code d’extension et de thème premium, le laisser accessible au public permettrait à n’importe qui de télécharger les produits que vous avez payés.

Une fois que vous avez terminé la configuration du nouveau projet, cliquez sur Créer un projet pour continuer.

Configurer les clés SSH

Ensuite, vous devrez ajouter des clés SSH à GitLab et MyKinsta pour permettre aux deux plateformes de communiquer entre elles. Commençons par ajouter une clé SSH dans GitLab.

Ajout d’une clé publique SSH pour GitLab

Tout d’abord, entrez en SSH dans votre environnement Kinsta, et lancez la commande du cat ci-dessous pour afficher votre clé publique SSH.

cat ~/.ssh/id_rsa.pub

Votre clé publique doit ressembler à celle ci-dessous. Gardez votre fenêtre de terminal ouverte pour l’instant, et retournez sur GitLab dans votre navigateur web.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC7zdjwd6UIUJ5t4YnXNi6yhdHgrvIV2xgjvJ3592wd1Hzmnta4dau7yOIxQDU7/oNIr6DIskuIUii5ruGi4YZpIwB/AWGrn/uWb+FXJFiQHMZq9rCFcqtZXT0fyzKiSNkblV4F1RaPQJRvxfSUsSQ3jJU3FX8CF1c4R40CiBKkSHM8uavVIIESzgIHRiWVxkL9F6SKzg8GeTctJaAa3W+q1F1T60OKYmzH3OLdA37ZNmkm1CYWa8SF0JjOszxOnPwhfQ49P5r+rftXRFLz/7hGJ8CnUyzErSiUdUKNknUAB+w4KEZshQSNuiken0+GKqIw83dWWSyjiJJigcyDez2s+3AqDLHPG45NoBEXuBXjPQ9C08hokVyKlbzd/P2qvcnzUT5S6zTuaYOW+50+fiXeYkJlEoYYxoGRVx6FFdFqWyJx5UyaDv7QY3iQH0qct1iq9XGXMhBxIecIAEPUwF8nOp15in8L+5UIFMiNnihztTAXysc+8xvVwbuRlQIeR/E= ansible-generated on fvj-kinstagit

Cliquez sur l’icône de l’utilisateur dans le coin supérieur droit de GitLab, puis cliquez sur Réglages.

Aller sur la page des réglages de GitLab.

Aller sur la page des réglages de GitLab.

Sur la page « Réglages », cliquez sur Clés SSH dans la colonne latérale.

Les clés SSH dans GitLab.

Les clés SSH dans GitLab.

Collez votre clé publique SSH dans le champ de texte. Le champ titre devrait se remplir automatiquement avec un nom, mais n’hésitez pas à le modifier si vous le souhaitez. GitLab vous permet également de définir une date d’expiration pour la clé SSH. Cette option est utile si vous invalidez et changez les clés SSH dans le cadre du protocole de sécurité de votre infrastructure. Si vous ne le faites pas, n’hésitez pas à laisser le champ « Expire le » vide.

Ajoutez votre clé SSH dans GitLab.

Ajoutez votre clé SSH dans GitLab.

Après avoir vérifié votre configuration, cliquez sur Ajouter une clé pour finaliser le processus.

Ajouter une clé publique SSH à MyKinsta

Maintenant que votre clé publique SSH a été attribuée à GitLab, vous devrez ajouter la même clé à MyKinsta. Dans MyKinsta, cliquez sur votre icône d’utilisateur dans le coin inférieur gauche et cliquez sur Réglages utilisateur. Cette étape ajoute la clé publique Kinsta au fichier authorized_keys de votre site (uniquement accessible en écriture par la racine et MyKinsta), et permettra à GitLab d’effectuer des changements de code en SSH sur votre site.

Réglages utilisateur dans MyKinsta.

Réglages utilisateur dans MyKinsta.

Faites défiler vers le bas et cliquez sur Ajouter une clé SSH.

Ajoutez une clé SSH dans MyKinsta.

Ajoutez une clé SSH dans MyKinsta.

Dans la fenêtre modale, indiquez un nom pour la clé SSH, collez votre clé publique dans le champ de texte et cliquez sur Ajouter une clé SSH pour finaliser le processus.

Ajoutez votre clé SSH dans MyKinsta.

Ajoutez votre clé SSH dans MyKinsta.

Ajouter une clé privée SSH à GitLab

Ensuite, vous devrez ajouter la clé privée SSH de votre environnement Kinsta en production comme variable d’environnement dans GitLab. La clé privée permettra à GitLab d’utiliser SSH dans votre site Kinsta afin de pousser les changements de code directement.

Pour trouver votre clé privée, exécutez la commande de terminal ci-dessous dans votre environnement Kinsta en production. Veillez à ne pas partager votre clé privée SSH en dehors du GitLab.

cat ~/.ssh/id_rsa

Dans GitLab, cliquez sur le projet que vous avez créé précédemment. Dans la colonne latérale, survolez « Réglages » et cliquez sur CI/CD.

GitLab repository CI/CD settings.

GitLab repository CI/CD settings.

Faites défiler la liste jusqu’à la section « Variables », cliquez sur le bouton « Développer », puis sur Ajouter une variable. Utilisez SSH_PRIVATE_KEY pour le nom de la clé, collez votre clé privée dans le champ de texte, et cliquez sur Ajouter une variable pour continuer.

Assurez-vous que vous ajoutez votre clé privée SSH. Elle doit commencer par -----BEGIN OPENSSH PRIVATE KEY-----

Une fois la variable ajoutée, vous pourrez la voir dans les réglages de votre dépôt.

Variable de clé privée SSH dans GitLab.

Variable de clé privée SSH dans GitLab.

Clone un dépôt GitLab vers MyKinsta

Maintenant que les clés SSH nécessaires ont été ajoutées, vous pouvez cloner votre dépôt GitLab dans votre environnement Kinsta en production. Dans GitLab, naviguez vers votre dépôt, cliquez sur le bouton bleu Cloner, et copiez l’URL sous « Cloner avec SSH ».

Clone avec SSH dans GitLab.

Clone avec SSH dans GitLab.

Ensuite, entrez en SSH dans votre environnement Kinsta en production et naviguez jusqu’à votre répertoire personnel. Si vous ne savez pas comment accéder à votre répertoire personnel, utilisez la commande ci-dessous.

cd ~/

Une fois que vous êtes dans le répertoire personnel, lancez la commande git clone avec l’URL que vous avez copiée depuis GitLab.

git clone [your-repository-url-here]

Après le clonage du dépôt, vous verrez un avertissement qui dit « vous semblez avoir cloné un dépôt vide ». Il faut s’y attendre car le dépôt est vide pour le moment.

Clonez votre dépôt GitLab dans votre environnement Kinsta.

Clonez votre dépôt GitLab dans votre environnement Kinsta.

Chez Kinsta, notre configuration Nginx sert le contenu du dossier ~/public. Ainsi, vous voudrez supprimer le dossier ~/public actuel et renommer votre dossier de dépôt cloné en ~/public. Pour ce faire, exécutez les deux commandes ci-dessous.

rm -rf ~/public
mv ~/your-repo-folder-name ~/public

Configurer le dépôt GitLab

Ensuite, utilisez la commande ci-dessous pour naviguer dans le dossier ~/public.

cd ~/public

Exécutez les deux commandes ci-dessous pour configurer votre dépôt GitLab. Veillez à indiquer une adresse e-mail valide et un identifiant de votre choix.

git config --global user.email "youremail@address.com"
git config --global user.name "brian"

Installer WordPress avec WP-CLI

Maintenant que le dépôt GitLab a été cloné dans votre environnement Kinsta en production et configuré, installons WordPress. Vous pouvez soit installer WordPress manuellement en le téléchargeant depuis wordpress.org, soit l’installer avec WP-CLI. Pour cet exemple, nous utiliserons WP-CLI pour installer WordPress avec la commande ci-dessous dans le dossier ~/public.

Vous avez des problèmes de temps d'indisponibilité et de WordPress ? Kinsta est la solution d'hébergement conçue pour vous faire gagner du temps ! Découvrez nos fonctionnalités
wp core download

Après l’installation de WordPress, votre dossier ~/public devrait ressembler à ceci.

Une nouvelle installation de WordPress avec WP-CLI.

Une nouvelle installation de WordPress avec WP-CLI.

Ensuite, allez à la page « Domaines » de MyKinsta pour votre site, et visitez votre « Domaine principal ».

Visitez votre domaine principal pour configurer WordPress.

Visitez votre domaine principal pour configurer WordPress.

Vous serez accueillis par le processus d’installation de WordPress, qui dure cinq minutes. Si vous n’êtes pas sûr de savoir comment installer WordPress, nous avons ici un guide détaillé.

Configurer la nouvelle installation de WordPress.

Configurer la nouvelle installation de WordPress.

Après l’installation de WordPress, vous devriez pouvoir voir votre nouveau site WordPress en visitant votre domaine principal.

Une nouvelle installation de WordPress.

Une nouvelle installation de WordPress.

Configurer le pipeline GitLab CI/CD

Ensuite, vous devrez créer un fichier de configuration spécial pour demander à GitLab de lancer des déploiements automatiques après la mise à jour de la marque principale du repo. Pour ce faire, accédez au dossier ~/public dans votre environnement Kinsta en production et créez un nouveau fichier appelé .gitlab-ci.yml avec la commande ci-dessous.

cd ~/public && touch .gitlab-ci.yml

Après la création du fichier, ajoutez le texte suivant au fichier. Vous pouvez modifier le fichier avec nano ou vim dans Terminal, ou avec un éditeur SFTP. Si vous utilisez un client SFTP, assurez-vous d’activer les fichiers masqués afin de voir le fichier .gitlab-ci.yml.

before_script:
    - apt-get update -qq
    - apt-get install -qq git
    # Setup SSH deploy keys
    - 'which ssh-agent || ( apt-get install -qq openssh-client )'
    - eval $(ssh-agent -s)
    - ssh-add <(echo "$SSH_PRIVATE_KEY")
    - mkdir -p ~/.ssh- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
deploy_live:
    type: deploy
    environment:
        name: Live
        url: your-primary-domain
    script:
        - ssh user@ip-address -p port-number "cd public-root && git checkout master && git pull origin master && exit"
    only:
        - master

Veillez à modifier les paramètres d'url et de script dans le bloc deploy_live. Vous devrez remplacer les valeurs en gras par les réglages de votre site dans le tableau de bord MyKinsta.

Public path and SSH details in MyKinsta.

Public path and SSH details in MyKinsta.

La section only : - masterdu fichier fait référence à la branche du dépôt qui déclenchera le processus CI/CD de GitLab. Avec cette configuration, les poussées vers la branche master initieront un déploiement vers votre environnement Kinsta en production. Si vous souhaitez spécifier une autre branche pour déclencher le déploiement, n’hésitez pas à modifier la configuration.

Si vous souhaitez ajouter une granularité supplémentaire à la configuration pour tenir compte d’un environnement de staging, vous pouvez ajouter un bloc deploy_staging supplémentaire avec l’URL et les détails SSH pour votre environnement de staging Kinsta.

deploy_staging:
    type: deploy
    environment:
        name: Staging
        url: your-staging-domain
    script:
        - ssh user@ip-address -p port-number "cd public-root && git checkout master && git pull origin staging && exit"
    only:
        - staging

Notez la section only : - staging – cela signifie que les poussées vers la branchestaging initieront le processus de CI/CD de GitLab.

Commit initial pour GitLab

Maintenant que WordPress et le fichier de configuration de GitLab sont configurés, faisons un premier commit à GitLab. Pour ce faire, nous allons créer une nouvelle branche appelée v0.1, commencer à suivre les fichiers dans le dépôt, valider les modifications et pousser les modifications vers GitLab sur la branche v0.1. Exécutez les commandes ci-dessous depuis ~/public pour déclencher le commit initial.

git checkout -b v0.1
git add .
git commit -a -m 'Initial Commit'
git push origin v0.1

Si vous vérifiez votre dépôt dans GitLab, vous verrez maintenant les fichiers de votre commit initial.

Commit initial pour GitLab.

Commit initial pour GitLab.

Configurer l’environnement de staging de Kinsta

L’étape suivante consiste à configurer un environnement de staging Kinsta afin de disposer d’un endroit sûr pour tester de nouvelles extensions, thèmes et codes sans impact sur votre environnement de production. Pour ce faire, créez d’abord un environnement de staging dans MyKinsta.

Créer un environnement de staging dans MyKinsta.

Créer un environnement de staging dans MyKinsta.

Entrez en SSH dans l’environnement de staging, et exécutez la commande ci-dessous pour vérifier les éventuels changements de code.

cd ~/public && git status

Vous devriez voir un message comme celui ci-dessous. Comme vous pouvez le voir, la branche est celle de la v0.1 qui a été créée précédemment. De plus, le fichier wp-config.php a été modifié. Cela se produit parce que Kinsta ajoute quelques lignes supplémentaires à wp-config.php pendant le passage de la production au staging.

Changement de fichiers dans l'environnement de staging de Kinsta.

Changement de fichiers dans l’environnement de staging de Kinsta.

Commit et pousser les changements en production

Enfin, nous allons apporter quelques changements à l’environnement de staging scène et pousser un nouveau commit dans l’environnement en production de Kinsta en utilisant GitLab. N’oubliez pas que le but de cette méthode est de contourner la fonction normale de « push to live » de Kinsta qui écrase également la base de données WordPress.

Pour cet exemple, installons l’extension Yoast SEO en utilisant WP-CLI avec la commande ci-dessous.

cd ~/public && wp plugin install wordpress-seo

Après avoir installé l’extension Yoast SEO, exécutez les commandes ci-dessous pour faire un commit et pousser les changements dans la branche v0.1.

git add .
git commit -a -m ‘Installed Yoast SEO plugin.’
git push origin v0.1

Enfin, passons à la branche master, fusionnons v0.1 avec master, et poussons master vers GitLab avec les commandes ci-dessous. Cela permettra à GitLab de lancer un processus de déploiement dans votre environnement Kinsta en production car le réglage only : - master est dans le fichier de configuration de GitLab.

git checkout master
git merge v0.1
git push origin master

Dans GitLab, allez dans CI/CD > Jobs dans la colonne latérale de votre dépôt, et vous verrez le travail en cours. Ce « job » est GitLab qui pousse l’extension Yoast SEO dans votre environnement Kinsta en production.

Active job in GitLab.

Active job in GitLab.

Une fois le travail terminé, lancez la wp plugin list sur votre environnement Kinsta en production. Vous devriez voir wordpress-seo – l’extension Yoast SEO qui a été installé plus tôt sur l’environnement de staging.

L’extesnion SEO Yoast a été déployée via GitLab.

L’extesnion SEO Yoast a été déployée via GitLab.

Si vous êtes un développeur de thèmes ou d’extensions qui travaille avec des sites Kinsta, la mise en place de déploiements automatiques via GitLab CI/CD peut vous aider à accélérer votre flux de travail. Cette configuration vous permet de déployer du code à partir de votre environnement local ou de l’environnement de staging Kinsta sans avoir à écraser la base de données MySQL sur votre site en production.


Si vous avez aimé ce tutoriel, alors vous allez adorer notre support. Tous les plans d’hébergement de Kinsta incluent le support 24/7 de nos développeurs et ingénieurs WordPress expérimentés. Discutez avec la même équipe qui soutient nos clients du Fortune 500. Découvrez nos plans