Migration (interne) AlwaysData à prévoir

[thbar]

On a reçu ça par email.

Important bits:

This migration must be completed by January 27, 2025

(donc on a le temps)

IMPORTANT: if this migration is not completed before the deadline, it will start automatically. We strongly encourage you to handle the migration yourself to avoid any risk of malfunction.

(donc il vaut mieux le déclencher que le subir)

Sachant qu'on utilise très peu de choses ça ne devrait pas être problématique, mais il vaut mieux anticiper.

Email d'AlwaysData

[alwaysdata] New migration: 2024 software infrastructure

Hello,

The migration “2024 software infrastructure” is now available. The major changes are:

• SSL is now required for mail protocols (IMAP, SMTP, POP3) and remote access protocols (FTP, WebDAV)
• MongoDB and CouchDB databases are removed
• MariaDB is upgraded to version 10.11
• PostgreSQL is upgraded to version 16

We encourage you to read the detailed list of changes (https://help.alwaysdata.com/en/advanced/migrations/2024-software-architecture/).

You can perform this migration from the administration interface, under the Advanced > Migrations section (https://admin.alwaysdata.com/migration/).

This migration must be completed by January 27, 2025 for the following accounts, belonging to antoine.augusti@beta.gouv.fr:

• transport-data-gouv-fr

IMPORTANT: if this migration is not completed before the deadline, it will start automatically. We strongly encourage you to handle the migration yourself to avoid any risk of malfunction.

Regards,

-- alwaysdata: https://www.alwaysdata.com/ help: https://help.alwaysdata.com/

[ptitfred]

J'ai lu 3 fois le message d'AlwaysData et toujours pas compris ce que ça implique pour nous :/

[thbar]

@ptitfred ça indique qu'on gagnera à partager un peu mieux ce qui est là bas à toi et @vdegove !

On n'utilise pas la grande majorité de leurs services, donc on aura a priori bien peu d'impact. Mais on a quand même le DNS, ce qui n'est pas rien 🤣

[thbar]

Voilà ce qu'on voit:

Ce que je préconise :

• on rafraîchit les backups de routes DNS (qu'on stocke en privé dans GitHub)
• puis on enclenche pro-activement la migration (pour que ça soit supervisé plutôt que subi)
• (et peut-être d'autres choses si d'autres idées viennent)

[thbar]

@ptitfred @vdegove les backups de "zone files" sont fait ici à la mano ; vous avez normalement accès au repo (privé).

https://github.com/etalab/transport-deploy

[thbar]

(si vous avez d'autres idées, n'hésitez pas, il n'y a pas urgence mais il vaut mieux qu'on soit un peu tous au courant, et c'est l'opportunité de mettre tout le monde au même niveau de connaissance ou d'accès dans @etalab/transport-tech)

[thbar]

Et hop, pour rafraîchir le backup tant qu'on y était:

• https://github.com/etalab/transport-deploy/pull/75

[AntoineAugusti]

J'avais fait un tour rapide de AlwaysData avec @ptitfred mais c'est vrai qu'on ne va pas régulièrement sur cette interface.

On utilise cet hébergeur pour DNS et configuration des e-mails.

Leur e-mail laisse penser qu'on n'aura pas d'impact : DNS n'est pas concerné et pour les e-mails on fait de la redirection vers Front, on n'est donc pas susceptibles de se connecter (IMAP, SMTP, POP3) sans SSL.