16 ms·

It varies a bit, but here are three approaches I've seen. 1. You build custom VM images that have everything you need baked in. You don't upgrade these VMs, in

It varies a bit, but here are three approaches I've seen. 1. You build custom VM images that have everything you need baked in. You don't upgrade these VMs, instead you build new ones and delete the old ones. 2. You use cluster management tools like Kubernetes or Nomad and run your software as containers. You upgrade by running a new version of the container. (If you choose to manage your own nodes in the cluster, you manage them as VMs using method 1.) 3. You don't run your software on servers you manage. You use so-called "serverless" services where your software doesn't have to think too hard about the OS it's running on.

postpawl 3y ago
Right, and the goal is to be able to easily deploy the same thing. Every time you SSH into a server and install something, you may not be getting the same packages due to updates or packages becoming unavailable. If you’re using an image, most likely you can easily tear stuff down and re-deploy it. Also you’ve got the code used to build the image and can modify it if necessary.
mercurialuser 3y ago
But you need to create: 1. A Custom vm image, so how do you do it? 2. A container: here is a bit simpler since you may use docer-compose...
- candiodari 3y ago
  Answer for both, really, look at docker config files. Essentially you specify what version of what distro to download, what to apt-get, what to download/git clone/... and you get out a VM image.
- a012 3y ago
  Hashicorp Packer is the tool to build VM images with the same idea as building a container image. I used it some years ago before moving to K8s completely
  - mercurialuser 3y ago
    Someone told me that our public facing dns server running bind has 3800+ days of uptime and despite bind is up to date, the Linux version is really old... it's running on a dl360 g4 server. Since they also proposed to have a different master/slave configuration my idea was to use ansible to have all the stuff reproducible. Then packer seemed to be necessary, then started to look at some more complex configurations and found that in many cases you just create gigantic bash script that apply the configurations. So I should go to my wiki page with all the commands to create my server and transform them into a script that I should test several times. Ok if you have 100s of identical servers, but when you have just 4?
    - dharmab 3y ago
      I used to use this automation pattern when I only had 2-3 of each type of server, and it paid off massively. Regular tasks that previously took a long time like OS upgrades, audit data collections and temporary dev access only took seconds or minutes, and ticket turnaround times dropped massively.
- dharmab 3y ago
  For 1. Hashicorp Packer For 2. You don't even need compose. Just build a container image from a Dockerfile.

postpawl 3y ago

Right, and the goal is to be able to easily deploy the same thing. Every time you SSH into a server and install something, you may not be getting the same packages due to updates or packages becoming unavailable. If you’re using an image, most likely you can easily tear stuff down and re-deploy it. Also you’ve got the code used to build the image and can modify it if necessary.

mercurialuser 3y ago

But you need to create: 1. A Custom vm image, so how do you do it? 2. A container: here is a bit simpler since you may use docer-compose...

candiodari 3y ago
Answer for both, really, look at docker config files. Essentially you specify what version of what distro to download, what to apt-get, what to download/git clone/... and you get out a VM image.
a012 3y ago
Hashicorp Packer is the tool to build VM images with the same idea as building a container image. I used it some years ago before moving to K8s completely
- mercurialuser 3y ago
  Someone told me that our public facing dns server running bind has 3800+ days of uptime and despite bind is up to date, the Linux version is really old... it's running on a dl360 g4 server. Since they also proposed to have a different master/slave configuration my idea was to use ansible to have all the stuff reproducible. Then packer seemed to be necessary, then started to look at some more complex configurations and found that in many cases you just create gigantic bash script that apply the configurations. So I should go to my wiki page with all the commands to create my server and transform them into a script that I should test several times. Ok if you have 100s of identical servers, but when you have just 4?
  - dharmab 3y ago
    I used to use this automation pattern when I only had 2-3 of each type of server, and it paid off massively. Regular tasks that previously took a long time like OS upgrades, audit data collections and temporary dev access only took seconds or minutes, and ticket turnaround times dropped massively.
dharmab 3y ago
For 1. Hashicorp Packer For 2. You don't even need compose. Just build a container image from a Dockerfile.