In case you're stuck compiling Kernel modules or running Docker, check out how it's done in the provisioner[2] that comes with the guide.
[1] https://github.com/hobby-kube/guide [2] https://github.com/hobby-kube/provisioning
Disclaimer: I'm the author of this project
https://thehftguy.com/2016/11/01/docker-in-production-an-his...
https://thehftguy.com/2017/02/23/docker-in-production-an-upd...
If you have issue with Kernels and Docker. It's not just you and it's not entirely the fault of the provider. ;)
>All CI pipelines in the world which rely on docker setup/update or a system setup/update are broken. It is impossible to run a system update or upgrade on an existing system. It’s impossible to create a new system and install docker on it.
If the loss of package repos counts as a critical outage for you, you should be running your own package mirrors. Especially if you're not paying for commercial support and don't have anyone to escalate issues to.
That's a crypto error interpretable as an active MITM attack on the repo, which causes a apt-get and subcommands to terminate abruptly with a critical error.
Last but not least, the repository is mirrored and cached, the mirrors simply reproduced the corrupted source repo :D
It is not a mere case of offline repository, though I can understand the confusion ;)
First commit done in 2014.
It's funny how people always mention workarounds that were non existent or non viable at the time of the issue. ;)
I have worked on mirrors a few times in my career. I am sadly well aware than even the best mirroring solutions are rather poor. Not gonna argue that they have flaws. Not gonna argue that we wish for better.
Nonetheless, it probably wasn't nearly as stable, and certainly wasn't as well-known then. So I'll concede that it may not have been viable at that point.
The Docker crypto fuckup was quite peculiar. The distribution pipeline can't handle that. It also broke their other repos (including ubuntu) and propagated to the mirrors.
(Docker multiarch support - or better say lack of one - is still a complete mess though. But that's also not a Scaleway issue.)
There are tricks to running your own kernel there (via kexec), for Arch it's neatly packaged here: https://github.com/stuffo/scaleway-archkernel (but new servers don't have Arch as an option)
Still, it's all terribly inconvenient. Possibly fun to mess with once, DIY/learning-style... but if you just want a server that works (and works in a way you want things to be, not how vendor had set it up) it could be sort of unpleasant.