How to backup your dedicated server on Object Storage with Duplicity – Scaleway

Automatize your backups with Duplicity and Scaleway Object Storage

Source : How to backup your dedicated server on Object Storage with Duplicity – Scaleway

Bien merci pour le tuto même s’il y a quelques petits glitches :).

De ceux que j’ai repéré :

  • le fichier scw-backups.sh au lieu de scw-backup.sh (en tout cas si on s’en réfère au CRON à la fin)
  • Sur debian 10 j’ai du faire avant de lancer l’install duplicity un apt-get install librsync-dev
  • Duplicity à ce jour est en 0.8.13 (nb ne pas installer la version debian trop vieille qui ne connais pas l’option glacier s3 par exemple)

A plus dans le bus !

Retour en 2013 / 2014 (nouvelle infra montaigu.io)

Je me demande jusqu’ou le retour dans le passé va aller. Me voilà dans une infra quasiment terminée. Et comparé à ce que je racontais dans cet article avec l’usage du kubernetes, depuis que j’ai décidé de revenir à l’ancienne mode, j’avance enfin. Les choses s’installent et fonctionnent enfin…

Le plus drôle c’est que finalement les outils que j’avais décidé de mettre en place aux alentours de 2014, Wallabag, freshRSS, Shaarli, DokuWiki sont finalement toujours maintenus et restent les compromis simple, open et efficace encore en 2020. Cela avec d’autres outils très sympas comme ISPConfig et Wekan.

Je vais enfin pouvoir démonter mes autres serveurs et me consacrer au fine tuning de la nouvelle infra. Ouf !

Jira applications installation requirements – Atlassian Documentation

For a small number of projects (less or equal to 100) with 1,000 to 5,000 issues in total and about 100-200 users, a recent server (multicore CPU) with 8GB of available RAM and a reasonably fast hard drive (7200 rpm or faster) should cater for your needs. However, if you’re using a 32-bit operating system, you shouldn’t allocate more than 1GB of RAM to Jira. If you’re manually installing/upgrading Jira on a 32-bit system by using the archive, you need to decrease the maximum heap size available to Jira. See the upgrade notes for more information.

Source : Jira applications installation requirements – Atlassian Documentation

Haha, cela répond à ma question précédente 🙂 Jira = 8G de RAM (sans parler de confluence à ajouter) vs wekan à 4Go si ma mémoire est bonne. Bon bah tant pis pour les 20$ les 10 users :).

Second retour sur la nouvelle infra alban.montaigu.io

Cet aticle fait suite au Premiers retours sur la nouvelle infra alban.montaigu.io.

Pour ce second retour je serai sans doute assez succinct sur certains aspects. Pour autant il est assez significatif: j’ai tout recommencé ! Alors que j’expliquais dans le précédent article que j’avais utilisé kubernetes, rancher, etc, le tout hébergé chez Scaleway, aujourd’hui je peux dire que j’ai tout supprimé 🙂

Finalement, je suis revenu sur une infra dans ce qu’il y a de plus classique. Même des choses que j’ai faite il y a 10 ou 15 ans…

  • Une simple VM, General purpose XS (pour avoir du SLA 99,99 et assez de CPU/RAM) chez scaleway.
  • Un operating system Debian 10 (retour aux racines…)
  • Une configuration à l’ancienne faite en mode shell et par l’usage de tutoriels triés sur le volet
  • Des outils aidant à l’administration en mode user friendly, le principal étant ISPConfig (Merci Olivier R. pour le conseil :))
  • Un bon vieux apache 2 (peut être moins performant dans certains cas, mais tellement mieux intégré partout avec tellement d’options pour faciliter la vie et surtout open)
  • Des déploiements de l’ensemble de mes sites sur la même machine et finalement front / middle / back sur la même VM.

C’est un gros revirement me direz vous. So why ? Pourquoi revenir à quelque chose que finalement je faisais déjà il y a 10 ans ? Eh bien les raisons sont multiples. Peut-être que c’est l’âge qui parle. Je me fais vieux. En veillissant j’ai le sentiment qu’on cherche de plus en plus la simplicité et l’efficacité.

Le fait est que pour l’infra basée sur Kubernetes, j’ai passé un certain temps (assez long, trop long) pour apprendre et surmonter toutes les problématiques juste pour redéployer mon blog. Avec parfois à la clé des choix cornéliens à faire sans parler de toutes les contraintes liées à l’architecture et son administration.

Le fait est que à chaque fois que je voulais ajouter un nouveau service ou avais une chose comme un upgrade à faire, je perdais des choses ou passait un temps bien trop long à traiter la chose / faire fonctionner. Parfois même en devant encore retoucher l’infra bas niveau voire en refaisant tout dans certains cas…

Le fait est que pour avoir un cluster kubernetes qui fonctionne avec des applications qui tournent sans se faire OOMKill je dois déployer des serveurs / noeuds supplémentaires qui me coutent cher (la mutualisation des ressources est bien plus délicate sur Kubernetes).

Alors oui, ou bout d’un moment, cela fatigue. Oui Kubernetes, Helm & co c’est hyper puissant. Oui j’ai réussi à faire des choses assez sexy. Mais voilà, à un moment, il faut en revenir au besoin : déployer un blog et quelques sites. Faire en sorte que ce soit simple que cela fonctionne efficacement et pour un cout modéré. L’état de l’art avec des déploiement n-tiers ? Pourquoi quand il s’agit d’avoir des sites à faible traffic sans SLA. L’état de l’art Kubernetes ? Pourquoi quand il s’agit de passer un minimum de temps d’administration et donc avoir une infra simple.

La conclusion s’impose alors d’elle même. Une VM à l’ancienne, un système entièrement configurable à un seul endroit avec des commandes simples connues depuis la nuit des temps. Pas de serveurs et de configuration dans tous les sens avec des 10aines d’outils et des commandes. Quand il s’agit de sauvegarder: snapshot & backup la VM. Quand il s’agit de restaurer, créer une vm depuis le snapshot & backup. Quand il s’agit de monitorer, utiliser des outils simples et connus depuis toujours. Pas d’orchestration complexe…

C’est simple, ça fonctionne, c’est à un seul endroit, c’est pas cher cela répond au besoin et c’est tout. Oui on peut faire plus à l’état de l’art technologique. Oui on peut faire des infra plus chiadées avec du n-tiers du cluster, de la réplication. Mais pourquoi faire quelque chose de si compliqué quand le service n’est pas critique ? Pourquoi introduire une complexité inutile ? Il y à un coût financier et humain à tout…

Finalemement je suis peut être juste trop vieux ou alors juste Kubernetes répond à des besoins de déploiement fréquents, de « workflows from dev to prod  » avec de la répétabilité et de l’automatisation à 100% à large échelle. Le tout quand on a une team conséquente avec des profils parfaitements formés / adaptés / nombreux.

Pour le reste, pour moi en tous cas, la mode « à l’ancienne » répond bien mieux au besoin. Finalement, pourquoi succomber à autre chose ? Bon ok je reste un peu geek, donc j’ai bien aimé découvrir et jouer. Mais voilà à un moment fini le jeu et le temps / les ressources sont comptées :).

Just Keep It simple, just KISS.

La suite au prochain épisode 🙂