Récemment, après avoir déployé une application Web sur un serveur dédié, nous avons réalisé que le stockage sur disque constituerait un futur goulot d'étranglement pour l'activité de l'application.
Cela nécessiterait un espace exponentiel pendant la durée d'utilisation de l'application, car elle sera finalement utilisée simultanément dans de nombreux endroits, tout en communiquant avec un serveur central chargé de télécharger des centaines de mégaoctets de ressources.
Nous avons décidé de déplacer le stockage de notre serveur dédié vers Amazon AWS S3 afin d'améliorer l'évolutivité de l'application.
Des choses faciles, pourrait-on dire à ce stade. Il suffit de changer de configuration dans Paperclip pour utiliser S3.
Eh bien, le problème était que l'application était déjà en production, donc le changement nous a obligés à déplacer tous les actifs existants vers le S3 afin d'éviter de perdre des données (évidemment !).
Au cours de nos recherches, nous avons trouvé une solution simple pour migrer tous les actifs vers S3. La solution sur Internet est assez simple ; il suffit d'envoyer le dossier dans lequel vos actifs sont stockés au S3 (le célèbre) public/system dossier) !
Cela fonctionnerait dans une situation où url de la configuration Paperclip a été définie précédemment. La valeur par défaut schéma que Paperclip utilise se retrouve dans un fichier dont l'emplacement est le suivant :
Pour ne pas perdre de temps à déterminer où /000/000/ est venue de, l'explication de tous les 0 en tête, et afin de créer une solution flexible, nous avons décidé d'élaborer notre propre stratégie.
Nous devons déplacer toutes les pièces jointes du modèle ;
Nous devons préserver tous les styles ;
Cela doit être fait sans verrouiller le serveur ;
Le bucket S3 doit être différent selon les environnements Rails (test, production, mise en scène) ;
Nous devons avoir un minimum de temps d'arrêt.
Nous devons d'abord être en mesure de changer la configuration de Paperclip pour utiliser S3 après la migration, et d'utiliser notre serveur pendant la migration (nous devons récupérer les fichiers joints).
Voici un modèle typique avec des pièces jointes :
Pour préparer le modèle à migrer vers le service S3, nous devons ajouter un commutateur qui peut être facilement activé.
Create un s3_migrate.yml fichier avec une certaine configuration :
De la ligne 1 à la ligne 4, c'est la configuration normale pour le stockage Paperclip S3. À la ligne 5, nous avons ajouté le commutateur pour activer le S3.
Si elle n'est pas activée, l'application doit diffuser les actifs depuis le serveur local. Nous modifierons ensuite la définition de notre modèle afin de refléter ces changements.
Dans cet extrait, nous stockons les options du Paperclip dans un hash (OPTIONS DE RANGEMENT POUR TROMBONES) et chargez le fichier contenant les options de migration. We fusionnons les paramètres S3 si l'activation est vraie.
Pour l'instant, nous avons préparé notre modèle pour passer à S3 une fois le processus de migration terminé.
Afin de migrer nos actifs vers S3, nous aurons besoin d'une tâche personnalisée pour effectuer l'action. Voici l'extrait qui en est responsable.
Create a name file paperclip_migrate.rake et mettez-le lib/tasks dossier et collez le code ci-dessus.
Exécutez la tâche :
**Une fois la migration terminée, nous devons mettre à jour notre fichier s3_migrate.yml et activer le stockage S3. **
Il suffit de changer la ligne activé verser vrai. Redémarrez le serveur Web et c'est terminé !
Remarque 1 : Le réglage du chemin dans s3_migrate.yml doit être égal à celui de la ligne 44 de la tâche. Modifiez cela en fonction de votre scénario.
Remarque 2 : Après avoir terminé la migration et vérifié que nos actifs ont été correctement migrés vers S3, vous pouvez supprimer les fichiers qui sont toujours stockés dans public/system.
Passons en revue nos exigences pour ce problème et validons chacune d'entre elles.
En ajoutant la possibilité de spécifier la classe et les objets de manière dynamique, on peut exécuter la tâche avec les modèles souhaités, par exemple :
C'est accompli !
Dans notre tâche, après avoir vérifié qu'il existe au moins un objet dans notre base de données, nous pouvons l'interroger pour récupérer tous les styles définis :
Cela vous donnera ce que nous attendons :
C'est accompli !
Nous utilisons une tâche rake pour effectuer la migration afin qu'elle puisse être exécutée sans affecter l'utilisation de l'application dans l'environnement de production.
C'est accompli !
Dans notre s3_migrate.yml nous définissons le chemin des actifs afin d'utiliser le Rails.env variable, de sorte que les actifs seront enregistrés en fonction de l'environnement dans lequel l'application est exécutée.
C'est accompli !
Nous n'avons besoin que d'un seul redémarrage du serveur Web ! On peut donc dire que l'exigence était...
C'est accompli !
Et c'est à peu près tout ce que vous devez savoir pour migrer les actifs Paperclip d'un serveur local vers Amazon S3.
Expérience dans les systèmes backend pour le Web utilisant des technologies de pointe. Développeur et créateur de produits Full Stack. Ruby/Rails, NodeJS, ElectronJS.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
