patternMinor
Is there a system which automates everything (OS release, and above) to host websites on?
Viewed 0 times
automateswebsitessystemandabovehostreleaseeverythingwhichthere
Problem
This is not really a DevOps question but more of a System Automation question (which DevOps covers only a part of, by popular opinion, so I hope it's okay).
I feel like some 5 USD IaaS VPS with Ansible could give me the peace of mind of technical stability for say 15 years on a
Everything above the OS will generally not get old because by Ansible (given a correctly orchestrated playbook) will continuously update and upgrade it.
Yet the fact that the OS will indeed get old can't get out of my mind. Transferring websites from one IaaS to another even once per 4 or 8 or 12 or 16 years is not something I want to do in principle. One could say, well, you can't eat the cake and keep it whole.
I thought of using PaaS but PaaS solutions wouldn't necessarily bring me that peace of mind as well because my data might be "thrown" in some server environment with an old OS (could be old as 20 or 25 years) without me even knowing that and not all PaaS companies guarantee streamed OS release_upgrade.
So, I desire some full system automation solution. Is there even such a thing which is usually stable and countable in earth in 2018? I ask this totally seriously, maybe I need to be less stressed about this, but maybe such technical solution (which isn't SaaS of course) exist and might suit my needs?
I just want to build my websites (usually Drupal) on the most automated, most upgraded system (OS and above) possible, in the budget of 5-30 USDs.
Note: I never provided hosting services and doesn't provide them now either - usually my websites are personal websites that only I myself manage.
I feel like some 5 USD IaaS VPS with Ansible could give me the peace of mind of technical stability for say 15 years on a
debian:stable system, but the debian:stable release itself will get old and vulnerable with the years.Everything above the OS will generally not get old because by Ansible (given a correctly orchestrated playbook) will continuously update and upgrade it.
Yet the fact that the OS will indeed get old can't get out of my mind. Transferring websites from one IaaS to another even once per 4 or 8 or 12 or 16 years is not something I want to do in principle. One could say, well, you can't eat the cake and keep it whole.
I thought of using PaaS but PaaS solutions wouldn't necessarily bring me that peace of mind as well because my data might be "thrown" in some server environment with an old OS (could be old as 20 or 25 years) without me even knowing that and not all PaaS companies guarantee streamed OS release_upgrade.
So, I desire some full system automation solution. Is there even such a thing which is usually stable and countable in earth in 2018? I ask this totally seriously, maybe I need to be less stressed about this, but maybe such technical solution (which isn't SaaS of course) exist and might suit my needs?
I just want to build my websites (usually Drupal) on the most automated, most upgraded system (OS and above) possible, in the budget of 5-30 USDs.
Note: I never provided hosting services and doesn't provide them now either - usually my websites are personal websites that only I myself manage.
Solution
TL;DR Pick software that focuses on long-term support. Use containers so that you can separate the runtime you need for your app from the security patching of the underlying infrastructure.
Long Answer:
I used to run some old PHP sites running popular content management systems. The plugins would fall out of support such that I could not upgrade the content management system else the plug-ins would break. So then I would stick on the latest major version things worked on and hope that no new security holes would come. I then ran monitoring software and manually fought off any scripts that got injected through security holes. Then the operating systems that support that old version of PHP I needed would fall out of support. I then couldn't easily move the hoster to take better use of cheaper deals or high availability. So I would find ports of the legacy PHP I needed onto the oldest version of an OS that hosters would support. Total nightmare.
What this demonstrated to me was that some software isn't built to last more than three or four years. Millions of sites would have had the same issues as me but tens of millions more wouldn't have as they would have been shutdown else rebuilt from scratch on newer software. So the first lesson here is that if you think you need to build for the long term you need to figure out if your using software that cares about long-term support and has a published lifetime.
The world has moved on and the PHP7 world is taking a new approach to having a predictable software release cycle and lifetime (still quite short I might add, but more predictable). You should not just assume nor expect any distro or any community to be with you for the long haul unless that is exactly what they said they are trying to do. And if that is what they are trying to do then they won't do other things that are in conflict with that such as run hot new framework features that are trending on stackoverflow.
These days I happen to be helping a company that is running Node.js 8 and PHP 7.x on RHEL7 containers on kubernetes on AWS. They get long-term support of security updates with a published lifetime. I have automated the detection of new security patches to the PHP and Node.js containers. A weekly job checks the upstream container registry and if there is a new security patched version it is announce to a team chat room along with the command to patch the containers in the test environment. A commercial subscription to those patches is included in my managed kubernetes hosting costs. Yet as its all opensource I could fall back to using Centos7 if I wanted to cut some costs.
As I am running containers I don't care whatsoever what patches are being applied to the IaaS nor the version of kubernetes I am hosted on. I am on openshift.com and they have upgraded to 3.11 through security fixes without telling me. They just patch the worker VMs and bounce them and kubernetes starts my containers on other VMs. I am insulated from all the security patching of the cluster I am on because I am running containers that have inside them the minimal operating environment needed to run my app. That only changes when I choose to upgrade to a new container and with long-term security patch support; I don't need to do that for years. I understand that the Kubernetes hosts that run my containers themselves run a very stripped down distro to maximise their security and customer density. It doesn't matter to me. The idea of an IaaS stack of Linux that goes out of support seems a totally alien concept to me now even through I lived many years with that problem.
It also means that I am free to move to any cloud or hosting provider that can run my containers. It doesn't have to be kubernetes it could be Docker Swarm or whatever. All that I am betting on is that this better way of working with containers will be supported in the long term. I think that's a good bet. A container image is only a json file naming a load of tar files that are the layers in the image. Yes; its just tar files and json. As long as the container host can load my files from a tar and attach a TCP/IP stack my stuff will run. I am pretty confident that this approach will have a very, very long shelf life.
I don't think that anyone that is trying to run apps should start out on IaaS today. PaaS is one solution but tends to have very strong vendor lock-in. CaaS is the new sweet spot. Choice. Stability. Control. Portability. If it runs under docker on your laptop just push it to the container orchestrator you are renting space on. My containers only have one thing in them. The hosts that they run on only does secure container hosting.
Long Answer:
I used to run some old PHP sites running popular content management systems. The plugins would fall out of support such that I could not upgrade the content management system else the plug-ins would break. So then I would stick on the latest major version things worked on and hope that no new security holes would come. I then ran monitoring software and manually fought off any scripts that got injected through security holes. Then the operating systems that support that old version of PHP I needed would fall out of support. I then couldn't easily move the hoster to take better use of cheaper deals or high availability. So I would find ports of the legacy PHP I needed onto the oldest version of an OS that hosters would support. Total nightmare.
What this demonstrated to me was that some software isn't built to last more than three or four years. Millions of sites would have had the same issues as me but tens of millions more wouldn't have as they would have been shutdown else rebuilt from scratch on newer software. So the first lesson here is that if you think you need to build for the long term you need to figure out if your using software that cares about long-term support and has a published lifetime.
The world has moved on and the PHP7 world is taking a new approach to having a predictable software release cycle and lifetime (still quite short I might add, but more predictable). You should not just assume nor expect any distro or any community to be with you for the long haul unless that is exactly what they said they are trying to do. And if that is what they are trying to do then they won't do other things that are in conflict with that such as run hot new framework features that are trending on stackoverflow.
These days I happen to be helping a company that is running Node.js 8 and PHP 7.x on RHEL7 containers on kubernetes on AWS. They get long-term support of security updates with a published lifetime. I have automated the detection of new security patches to the PHP and Node.js containers. A weekly job checks the upstream container registry and if there is a new security patched version it is announce to a team chat room along with the command to patch the containers in the test environment. A commercial subscription to those patches is included in my managed kubernetes hosting costs. Yet as its all opensource I could fall back to using Centos7 if I wanted to cut some costs.
As I am running containers I don't care whatsoever what patches are being applied to the IaaS nor the version of kubernetes I am hosted on. I am on openshift.com and they have upgraded to 3.11 through security fixes without telling me. They just patch the worker VMs and bounce them and kubernetes starts my containers on other VMs. I am insulated from all the security patching of the cluster I am on because I am running containers that have inside them the minimal operating environment needed to run my app. That only changes when I choose to upgrade to a new container and with long-term security patch support; I don't need to do that for years. I understand that the Kubernetes hosts that run my containers themselves run a very stripped down distro to maximise their security and customer density. It doesn't matter to me. The idea of an IaaS stack of Linux that goes out of support seems a totally alien concept to me now even through I lived many years with that problem.
It also means that I am free to move to any cloud or hosting provider that can run my containers. It doesn't have to be kubernetes it could be Docker Swarm or whatever. All that I am betting on is that this better way of working with containers will be supported in the long term. I think that's a good bet. A container image is only a json file naming a load of tar files that are the layers in the image. Yes; its just tar files and json. As long as the container host can load my files from a tar and attach a TCP/IP stack my stuff will run. I am pretty confident that this approach will have a very, very long shelf life.
I don't think that anyone that is trying to run apps should start out on IaaS today. PaaS is one solution but tends to have very strong vendor lock-in. CaaS is the new sweet spot. Choice. Stability. Control. Portability. If it runs under docker on your laptop just push it to the container orchestrator you are renting space on. My containers only have one thing in them. The hosts that they run on only does secure container hosting.
Context
StackExchange DevOps Q#5674, answer score: 5
Revisions (0)
No revisions yet.