Comment j'ai construit un remplacement pour Heroku et réduit mes coûts de plate-forme de 4X

Vous pouvez passer à la section Que fait-il si vous souhaitez accéder directement à l'entreprise.

MISE À JOUR 2019 : CaptainDuckDuck est maintenant rebaptisé et distribué sous le nom de CapRover. Voir //github.com/caprover/caprover

La douleur

Il y a quelques années, j'ai commencé à jouer avec des langages côté serveur - principalement Node JS. Après quelques jours de lutte, j'ai pu déployer une application Hello World sur mon localhost. C'était amusant, jusqu'à ce que je décide de passer à l'étape suivante et de déployer l'un de mes projets sur Internet afin que les gens puissent y accéder à partir d'une URL publique comme //www.some-awesome-web-app.com.

À ce stade, j'ai réalisé qu'il y avait un tout nouvel ensemble de technologies que je devais apprendre pour déployer mon application Web. J'avais besoin de savoir comment créer des outils et des pipelines de déploiement, comment fonctionnent le routage nginx et SSL, et bien d'autres choses encore…

Inutile de dire que le déploiement a été une expérience douloureuse. J'ai réalisé que je devais passer presque le même temps que j'ai passé à coder sur le déploiement de code sur le serveur, la construction, l'installation des dépendances et la maintenance du serveur. C'est tout simplement stupide! J'ai dû passer du temps à faire les mêmes choses encore et encore.

Je préfère passer mon temps à coder un produit / service qui sera utilisé par les utilisateurs, sans passer des heures et des jours à configurer HTTPS. Après tout, mon HTTPS n'est pas différent des autres centaines de milliers de sites Web HTTPS sur Internet. Il devait y avoir un moyen plus simple.

Le sauveur temporaire

Cette douloureuse expérience a pris fin lorsque je suis tombé sur Heroku, une plateforme prête à l'emploi pour le déploiement d'applications. Je me suis dit «Super! Voilà ce qu'une plate-forme de déploiement doit être! » J'ai adoré la façon dont ils ont résumé toute la complexité derrière une interface simple. Vous pouvez simplement créer une application d'un simple clic et la pousser. Il devient immédiatement disponible avec une URL publique. Il est disponible gratuitement avec un petit coût de sommeil après 30 minutes d'inactivité. Les choses ne pourraient pas être mieux!

Tout était bon. Jusqu'à ce que je sois impliqué dans certains projets qui nécessitaient une exécution continue 24h / 24 (un bot lecteur). J'ai dû passer au service payant. Ce n'était pas trop mal, seulement 7 $ par mois. Mais les choses ont commencé à devenir folles après avoir commencé à déployer de plus en plus d'applications. Certains étaient des projets personnels, et certains étaient liés aux affaires qui nécessitaient soit plus de 512 Mo (limite libre) de RAM, soit une disponibilité continue 24h / 24.

Il n'a pas fallu trop de temps pour me rendre compte que je payais plus de 100 $ à Heroku. Cela n'avait tout simplement aucun sens. Certains de mes robots lecteurs qui nécessitent une disponibilité 24h / 24 ne consomment que 128 Mo de RAM. Pourtant, j'ai également dû payer pour la RAM inutilisée. Je ne pouvais pas partager la RAM / CPU entre les applications. Cela empire avec les applications à forte utilisation de la RAM. Si j'ai une application qui nécessite 1 Go de RAM, je dois payer au minimum 50 $ par mois.

Dans l'espoir de trouver de meilleures offres, j'ai commencé à chercher AWS, Digital Ocean, Vultr et d'autres fournisseurs de serveurs. Le prix que j'ai vu m'a tout simplement époustouflé. Sur Digital Ocean, par exemple, je pourrais obtenir un serveur avec 2 Go de RAM pour 20 $ par mois. Je pourrais installer 2 instances de mon 1 Go de RAM dans cette machine pour 20 $ au lieu de 100 $. Je pourrais réduire mes coûts de 4x !

Il y a un piège à ce prix moins cher. Si vous ne savez pas ce que c'est, vous n'avez pas lu le premier paragraphe, The Pain . Le problème avec l'utilisation de ces fournisseurs de serveurs barebones (par opposition à des services comme Heroku) est que je dois faire tout le travail que Heroku a fait pour moi.

À la recherche du Sauveur éternel

Je savais ce que je voulais: j'avais besoin de quelque chose qui transforme un serveur barebone (comme AWS ou Digital Ocean) en une plate-forme semblable à Heroku. Au fur et à mesure que je gagnais en expérience, je savais qu'il devait y avoir une sorte d'équivalent open-source à Heroku quelque part assis sur Github. Effectivement, j'avais raison. Il n'y en a pas qu'un, mais une tonne.

Cependant, après avoir passé une heure ou deux avec chacun d'eux, je me suis rendu compte qu'aucun d'entre eux n'était la solution vraiment Heroku-easy que je recherchais. Certains étaient super basiques et avaient juste une fine couche d'interface avec peu ou pas de documentation. Certains étaient extrêmement avancés avec des tonnes de fonctionnalités qui n'étaient pas utilisées. Et avoir ces fonctionnalités signifiait simplement un processus de configuration et de maintenance compliqués. Je cherchais une solution simple mais performante.

Construire le Sauveur éternel

Comme je n'avais pas de chance de trouver un bon remplaçant pour Heroku, j'ai décidé d'en construire un. Heureusement, tous les outils dont j'avais besoin étaient disponibles gratuitement - du serveur Web HTTP nginx pour les demandes de routage, à Docker pour la conteneurisation des applications, etc.

Après quelques mois de planification, de conception, de construction, de suppression et de départ de zéro, le projet était prêt.

J'ai sorti la version initiale de CaptainDuckDuck en octobre 2017. Cela ne fait que deux mois environ et il y a eu une tonne de retours positifs. Après la première version, qui était principalement destinée au déploiement d'applications Web, la communauté en a demandé plus. Ils voulaient principalement la possibilité de déployer des bases de données et des applications en un clic. Cette semaine, j'ai publié la version 0.2.1 avec toutes ces fonctionnalités demandées :)

Qu'est ce que ça fait

Mon objectif était de permettre à un développeur d'application Web typique de créer une instance de serveur de type Heroku en moins de 10 minutes. Je suis heureux de dire que je l'ai fait!

Vous copiez et collez simplement une ligne sur votre serveur et vous aurez votre propre Heroku.

  • Vous pouvez déployer des applications Web (nodejs, php, etc.) avec une simple commande de déploiement CLI.
  • Vous pouvez activer HTTPS en cliquant simplement sur le bouton «Activer HTTPS».
  • Vous pouvez choisir parmi des applications / bases de données en un clic telles que WordPress, MongoDB, MySQL, Parse et autres.
  • Vous pouvez connecter plusieurs serveurs pour créer un cluster de serveurs en entrant simplement les adresses IP et les informations d'identification des serveurs dans l'interface utilisateur Web.

CaptainDuckDuck est écrit en NodeJS. Mais ce n'est pas le NodeJS avec lequel vos utilisateurs finaux traitent. Les principaux moteurs que Captain utilise sous le capot sont le nginx et le docker. Les deux sont parmi les outils les plus fiables et prêts pour la production. La partie NodeJS du CaptainDuckDuck n'est utilisée que lors du déploiement d'une application sur le serveur. Théoriquement, vous pouvez tuer le processus CaptainDuckDuck sur votre serveur après le déploiement et les utilisateurs ne remarqueront aucun changement.

Didacticiel

Si vous voulez un guide complet, je vous recommande de regarder le didacticiel vidéo et de lire la page Github. La vidéo a été réalisée avec la première version, elle n'a donc pas de base de données et d'applications en un clic. Mais c'est un bon point de départ.