RailsConf 2018: Operating Rails in Kubernetes by Kir Shatrov

[@elissonmichael2807]

Thanks for sharing this.

[@zbigh]

Kubernetes Job that runs migrations before deployment works well. Check this approach out guys.

[@collimarco]

What about the old code running on the new database schema while Kubernetes updates all the pods? Any solutions? Or you just accept that there can be errors for some minutes?

[@KingHafify]

@@collimarco i think he idea is to write migration that will work with both new and old code. So instead of `rename_column`, you add new column and keep the old column.

[@konkerouf]

assets => "the efficient way to do that is to embed assets in the container" NO! the efficient way to do that is to not use rails pipeline and manage your web assets separately like you would manage your phone apps (and any other client) assets separately.

[@ThomasBromehead]

Hi Florian, I am dealing with that right now. Currently working on an app and have my assets in app/assets - and including them in my image. What would you recommend, removing them and doing a docker cp into the app/assets of the container (which means using the assets pipeline) in an entry point script for example? Of rsyncing them to my nginx container into /public ? What’s your approach?

[@ThomasBromehead]

By the way je suis français aussi ;)

[@konkerouf]

​@@ThomasBromehead Alors t'as plusieurs solutions possibles 1) si tu utilises rails 6+, vu que ca utilise webpacker, moi je bougerai tout dans un projet separe qui utilise webpack pour la compilation. La transition devrait pas etre super complexe. Comme ca, tes assets ont leur propre repo, tu passes ton appli rails en mode API, tu reduis ta consommation de memoire... 2) si tu peux pas extraire, tu fais 2 pipelines de deploiement, une pour l'app rails a proprement parler et une pour les assets. Dans celle de l'app, tu construis une image docker et tu la deploies. Dans celle des assets, tu utilises la meme images que celle de l'app rails mais tu fais juste tourner la compilation et tu deploies (avec un stockage temporaire au milieu peut etre) uniquement les assets. Personnellement, mes assets ne font pas du tout partie de rails. 0 js, 0 image, 0 css. Quand je veux un client, je fais un autre projet qui n'a strictement aucun rapport avec rails (pour la solution que je dev, j'ai 4 clients JS, 3 clients C#). Chacun a son propre repo, ses propres pipelines, son propre CI, et un systeme de repo prives pour le code partage (npm pour JS ET C# puisque le C# c'est du unity et que unity accepte NPM pour certains types de dependances). Mon appli rails ne sert que du json en mode API (REST et/ou GraphQL). Mes images docker sont minuscules (72Mo, j'utilise alpine), alors que si tu mets tes assets dedans, tes images vont grossir avec le temps. Si je veux deployer une nouvelle version de lapp rails, j'ai pas attendre que les assets se compilent. Si je veux deployer une nouvelle version d'un client, j'ai pas besoin de compiler les 7 (surtout que les clients C# se deploient dans des casques VR donc hors de question qu'un push rails declenche aussi un push sur les HMD). Pour l'anecdote, je bossais sur une app avec un enorme paquet d'assets. On avait 3 clients, bien fats, avec des melanges batards de haml et autres trucs exotiques (donc durs a extraire de rails asset pipeline). Evicemment, c'etait avant rails 6, donc pas de webpacker. Compiler les assets prenait plus de 25 minutes. Quand on avait un hotfix ou un rollback a deployer, pendant 25 minutes de compilation + le temps de telecharger les images qui etaient absolument enormes, la prod etait petee. Le jour ou on s'est enfin debarasse de cette merde, le deploiement (rails) est passe a 2 minutes. Et le truc, c'est que le temps de compilation d'assets est proportionnel au volume donc ca ne peut que grossir si la codebase grossit. Alors que construire une image rails "pure" non (seulement le temps de copie des fichiers ruby, ce qui est negligeable). Donc si tu veux pouvoir reagir rapidement en cas de bug, autant ne pas paralyser toute ta stack avec les assets. Mes clients webs sont deployes dans un CDN, pas dans nginx. Comme ca jai du bon gros cache des familles, avec des replications disposees un peu partout dans le pays, l'invalidation est super simple et je n'utilise pas des sockets de nginx et/ou rails pour telecharger des assets (c'est S3 et cloudfront qui charbonnent, ce qui n'est pas mon probleme). Chacun son job et chacun ses ressources! :D PS: aussi, ma config kubernetes est nettement plus simple sans assets

[@ThomasBromehead]

@@konkerouf Salut Florian, Merci pour ton retour ultra détaillé, on sent l’expérience ;) et je m’attendais pas à une telle réponse donc merci d’avoir pris le temps! Pour ma part je vais faire du server-side rendered en traditionnel donc pas de Rails en mode API, mais oui, pas envie de polluer mon image avec des assets inutilement… L’idée de décomposer en 2 pipelines me plaît bien, pour le déploiement je visualise pas trop, pour moi je continue à déployer sur un nginx dédié aux assets et le cache n’est qu’une redirection DNS, tu déploies directement sur ton CDN, je ne suis pas familier avec ça mais j’ai clairement moins d’XP que toi.
Si tu as 5 min je serai preneur de discuter de vive voix avec toi, tu es freelance? Ou es-tu basé?
A+

[@ThomasBromehead]

@@konkerouf Hello, en Chine d'accord eh be, sacrée aventure! Je vois ce qu'est un CDN, j'utilise Cloudflare par exemple. C'est cette phrase que j'ai du mal à comprendre je pense (mes clients webs sont déployés dans un CDN, pas dans nginx). A+