Le lancement d'Upsun a été une période passionnante et, comme vous pouvez l'imaginer, nous avons tous fait beaucoup d'expériences. Nous testons les limites des frameworks que nous avons toujours voulu déployer, en utilisant Upsun comme une excuse parfaite pour prendre une heure ou deux pour les essayer.
Nous effectuons également de nombreuses migrations. Nous prenons des sites souvent déployés sur Platform.sh et comparons leur configuration, leurs performances et la flexibilité de leurs ressources sur Upsun.
Nous avons donc été ravis lorsqu'un collègue a apporté dans notre canal Slack un projet de portfolio artistique WordPress qu'il essayait de migrer avec les spécifications suivantes :
Ce billet a pour but de partager ce que j'ai fait pour l'aider à migrer ce projet vers Upsun depuis Platform.sh. N'hésitez pas à suivre l'expérience, mais notez que j'ai :
console.upsun.com
Et il en va de même pour Platform.sh. Maintenant, entrons dans le vif du sujet !
J'ai commencé par travailler à partir du projet original sur Platform.sh, auquel nous ferons référence ici avec l'ID de projet Xplatform-shX
. Nous allons le migrer vers un projet sur Upsun, auquel nous ferons référence ici avec l'ID de projet YYYYupsunYYY
. Pour configurer un projet en vue de sa migration de Platform.sh vers Upsun, procédez comme suit :
platform get Xplatform-shX
upsun project:create
upsun project:set-remote YYYYupsunYYYY
Comme vous avez pu le constater, la configuration pour Upsun est plus ou moins la même que pour Platform.sh. Les seules différences que vous pouvez remarquer dans ce processus sont liées à la combinaison des fichiers de configuration ou à la suppression des attributs utilisés pour configurer les ressources sur Platform.sh - la nouvelle API de ressources est le principal facteur de distinction d'Upsun.
Pour configurer notre projet WordPress Platform.sh pour Upsun, j'ai suivi les étapes suivantes :
1. Le projet Platform.sh partagé par notre collègue contenait ce que vous attendez : les fichiers .platform.app.yaml
, .platform/services.yaml
et .platform/routes.yaml
. Nous avons maintenant - à partir de project:set-remote - un
répertoire .upsun
auquel nous pouvons ajouter un fichier .upsun/config.yaml
. Dans ce fichier, j'ai inclus toutes mes configurations Platform.sh sous des clés assez intuitives :
# .upsun/config.yaml applications : app : type : "php:7.4" dépendances : php : wp-cli/wp-cli-bundle : "^2.4" psy/psysh : "^0.10.4" relations : database : "db:mysql" variables : php : ... web : locations : "/" : ... "/wp-content/cache" : ... "/wp-content/uploads" : ... disk : 19400 mounts : "public_html/wp-content/cache" : source : local source_path : "cache" "public_html/wp-content/uploads" : source : local source_path : "uploads" hooks : deploy : | ... services : db : type : mariadb:11.2 disk : 512 routes : "https://{default}/" : type : upstream upstream : "app:http" cache : enabled : true cookies : ... "https://www.{default}/" : type : redirect to : "https://{default}/"
Tout est maintenant dans un seul fichier. Les services sont sous services
, les routes sous routes
, et l'application unique(app
) est sous applications
(maintenant sous la clé app
au lieu d'utiliser l'attribut name
de Platform.sh).
2. Sur Upsun, comme mentionné précédemment, les ressources sont configurées via l'API plutôt que YAML. Pour cette raison, nous devons supprimer les définitions de disque
pour l'application(app
) et la base de données du
service MariaDB.
3. Enfin, les _types_ de montages sur Platform.sh ne sont pas tout à fait les mêmes que les options sur Upsun. C'est-à-dire que nous devons mettre à jour nos deux montages pour utiliser le type storage
au lieu de local
pour l'attribut source
. Le raisonnement derrière cela se résume au nommage - les montages sur Upsun ne sont pas locaux de la même manière. N'importe quel conteneur d'application peut être étendu à plusieurs instances, ce qui nécessite que les données de ce qui était auparavant un montage local
soient partagées entre elles. storage
est juste un meilleur nom pour ce comportement, et pour une instance unique, le comportement est identique à Platform.sh. Pour ceux d'entre vous qui sont curieux, en coulisse, ce type de montage est en fait un service de stockage réseau.
Toutes ces modifications aboutissent à un fichier de configuration final, comme celui-ci :
# .upsun/config.yaml applications : app : type : "php:7.4" dépendances : php : wp-cli/wp-cli-bundle : "^2.4" psy/psysh : "^0.10.4" relations : database : "db:mysql" variables : php : ... web : locations : "/" : ... "/wp-content/cache" : ... "/wp-content/uploads" : ... mounts : "public_html/wp-content/cache" : source : storage source_path : "cache" "public_html/wp-content/uploads" : source : storage source_path : "uploads" hooks : deploy : | ... services : db : type : mariadb:11.2 routes : "https://{default}/" : type : upstream upstream : "app:http" cache : enabled : true cookies : ... "https://www.{default}/" : type : redirect to : "https://{default}/"
Avec notre configuration en place, nous pouvons tester le projet avec un push upsun
.
Maintenant, si vous suivez la migration de votre propre projet WordPress vers Upsun, juste avant que le hook de déploiement ne soit exécuté, vous remarquerez quelque chose comme ceci :
Configuration des ressources Utilisation des tailles par défaut Réglage de la taille du profil 'app' à '0.5'. Réglage du disque 'app' à '512MB'. Réglage de la taille du profil 'db' à '0.5'. Réglage du disque 'db' à '512MB'.
Création de l'environnement principal Démarrage de l'environnement Ouverture de l'application et de ses relations Exécution du crochet de déploiement pour l'application ... Ouverture de l'environnement Configuration de l'environnement app (type : php:7.4, cpu : 0.5, memory : 224, disk : 512) mariadb (type : mariadb:10.11, cpu : 0.5, memory : 1408, disk : 512)
Bien que l'API des ressources vous permette de modifier les ressources disponibles pour vos conteneurs et environnements, Upsun définira automatiquement des valeurs par défaut raisonnables lors de votre première exécution.
Il n'y a rien à faire ici, juste quelque chose d'agréable à souligner, je pense.
Lorsque l'activité est terminée, nous avons l'écran d'installation de WordPress, c'est-à-dire tout notre code mais aucune de nos données. Nous allons donc migrer ces données, en commençant par ce qui suit :
platform db:dump
platform mount:download
Et comme ce projet de migration particulier était un site web de portfolio artistique avec près de 15 Go d'œuvres d'art dans les montages, je me suis éclipsé pour un épisode de Ted Lasso pendant que le téléchargement se terminait. Une fois le téléchargement terminé, tous les fichiers téléchargés se trouvaient dans les ressources de notre nouveau projet Upsun. Vous pouvez mettre à jour ces ressources avec la commande CLI upsun resources:set
. Ici, j'ai gardé tout ce qui existait auparavant, en augmentant seulement le disque alloué à l'application
jusqu'à 20048
Mo.
Ensuite, la même chose que précédemment en sens inverse pour télécharger les données :
upsun sql < ZZZZ...ZZZZ--dump.sql
upsun mount:upload
Et juste comme ça, notre projet - à l'exception de l'ajout de notre domaine - aété migré vers Upsun à partir de Platform.sh.
Maintenant que nous avons terminé, nous pouvons
Bonne chance pour vos propres migrations ! Rejoignez notre communauté pour nous tenir au courant.