5 ms·

The problem is Vagrant + Ansible violates the rule of "build once." I don't care about the isolation for isolation sake, I care about it for the artifact sake.

by grhmc 11y ago

crdoconnor 11y ago
I don't care so much for this rule. It sounds like a figleaf covering for broken build scripts. I care about tracking down issues before they reach production. Meaning that I want an environment that mirrors production as closely as possible. Meaning heavyweight not lightweight virtualization.
- grhmc 11y ago
  Agreed about preventing issues getting to production, but that doesn't exclusively mean heavyweight virtualization. It also doesn't "cover up" broken build scripts. Our build scripts get tested a dozen times a day and cannot tolerate half-assed broken build scripts. Our deployment pipeline (after verifying the image is good enough to be deployed) packs the docker image into a machine image along with several other containers. The machine image is then deployed to staging. If the machine image passes staging, it goes to production. If there is an issue which has hit production exclusively (it has happened only a handful of times,) it is simply an issue of rolling back to the previous machine image.
  - crdoconnor 11y ago
    >Agreed about preventing issues getting to production, but that doesn't exclusively mean heavyweight virtualization. Well, it gets you a step closer to accurately mimicking production. >It also doesn't "cover up" broken build scripts. That seems to be what that 'build once' rule is for. If your building process isn't risky, why the need to prohibit running it twice?
    - josegonzalez 11y ago
      So that your build process is faster. If I can use the same container for local dev, continuous integration, staging, and production, that means I only had to build it once and the pipeline to get something from a developer's laptop to a production instance is much quicker. Just because I can install the operating system doesn't mean I want to do this on every deploy of an application.
  - grhmc 11y ago
    It is far easier and less risky to only run it once and use that artifact than to make sure every environment it could possibly build in is identical. Keeping all your environments perfectly identical is more likely to either: 1. introduce subtle differences you aren't even aware of, or 2. introduce DLL-hell at datacenter scale.
caw 11y ago
How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file? You can use both tools to build an image once and then rebuild for the updates. I don't see how the tool in any way violates that constraint. What is this rule to only build once? I can see not wanting to create multiple artifacts of your codebase, but with machines it is possible to continually update them and sometimes desirable as well. In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once. The physical servers need to get updated and managed post-install.
- grhmc 11y ago
  > How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file? Unless you're snapshotting that vagrant box and then deploying that to all your servers somehow, you are building multiple times. > What is this rule to only build once? I'd recommend reading the book Continuous Delivery. It is a fantastically helpful read. I prefer not to update my machines, but that is because I follow immutable deployments. But, even if I did update my machines, it is far cleaner (and easier to roll back!) to deploy an asset which has all its dependencies in the box. than to push out code and maybe have to upgrade or install new packages. The gemfile.lock and friends make this a bit less of a problem, but you also get to lock things like libxml version or ffmpeg or... > In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once. Totally true, and we don't do this. We build a machine image and do a rolling-deploy replacing existing servers with the new machine image. > The physical servers need to get updated and managed post-install. One of the reasons I try not to work with hardware. Physical hardware is hard, and avoiding it makes my life much simpler. I love it.
  - crdoconnor 11y ago
    >Unless you're snapshotting that vagrant box and then deploying that to all your servers somehow, you are building multiple times. You're also configuring many things in many different potentially complex ways. The docker method of using environment variables as a configuration hack to get around this is pretty horrible, IMHO. Especially compared to ansible's YAML/jinja2 configuration.

The problem is Vagrant + Ansible violates the rule of "build once." I don't care about the isolation for isolation sake, I care about it for the artifact sake.

by grhmc 11y ago

The problem is Vagrant + Ansible violates the rule of "build once." I don't care about the isolation for isolation sake, I care about it for the artifact sake.

crdoconnor 11y ago

I don't care so much for this rule. It sounds like a figleaf covering for broken build scripts. I care about tracking down issues before they reach production. Meaning that I want an environment that mirrors production as closely as possible. Meaning heavyweight not lightweight virtualization.

grhmc 11y ago
Agreed about preventing issues getting to production, but that doesn't exclusively mean heavyweight virtualization. It also doesn't "cover up" broken build scripts. Our build scripts get tested a dozen times a day and cannot tolerate half-assed broken build scripts. Our deployment pipeline (after verifying the image is good enough to be deployed) packs the docker image into a machine image along with several other containers. The machine image is then deployed to staging. If the machine image passes staging, it goes to production. If there is an issue which has hit production exclusively (it has happened only a handful of times,) it is simply an issue of rolling back to the previous machine image.
- crdoconnor 11y ago
  >Agreed about preventing issues getting to production, but that doesn't exclusively mean heavyweight virtualization. Well, it gets you a step closer to accurately mimicking production. >It also doesn't "cover up" broken build scripts. That seems to be what that 'build once' rule is for. If your building process isn't risky, why the need to prohibit running it twice?
  - josegonzalez 11y ago
    So that your build process is faster. If I can use the same container for local dev, continuous integration, staging, and production, that means I only had to build it once and the pipeline to get something from a developer's laptop to a production instance is much quicker. Just because I can install the operating system doesn't mean I want to do this on every deploy of an application.
- grhmc 11y ago
  It is far easier and less risky to only run it once and use that artifact than to make sure every environment it could possibly build in is identical. Keeping all your environments perfectly identical is more likely to either: 1. introduce subtle differences you aren't even aware of, or 2. introduce DLL-hell at datacenter scale.

caw 11y ago

How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file? You can use both tools to build an image once and then rebuild for the updates. I don't see how the tool in any way violates that constraint. What is this rule to only build once? I can see not wanting to create multiple artifacts of your codebase, but with machines it is possible to continually update them and sometimes desirable as well. In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once. The physical servers need to get updated and managed post-install.

grhmc 11y ago
> How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file? Unless you're snapshotting that vagrant box and then deploying that to all your servers somehow, you are building multiple times. > What is this rule to only build once? I'd recommend reading the book Continuous Delivery. It is a fantastically helpful read. I prefer not to update my machines, but that is because I follow immutable deployments. But, even if I did update my machines, it is far cleaner (and easier to roll back!) to deploy an asset which has all its dependencies in the box. than to push out code and maybe have to upgrade or install new packages. The gemfile.lock and friends make this a bit less of a problem, but you also get to lock things like libxml version or ffmpeg or... > In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once. Totally true, and we don't do this. We build a machine image and do a rolling-deploy replacing existing servers with the new machine image. > The physical servers need to get updated and managed post-install. One of the reasons I try not to work with hardware. Physical hardware is hard, and avoiding it makes my life much simpler. I love it.
- crdoconnor 11y ago
  >Unless you're snapshotting that vagrant box and then deploying that to all your servers somehow, you are building multiple times. You're also configuring many things in many different potentially complex ways. The docker method of using environment variables as a configuration hack to get around this is pretty horrible, IMHO. Especially compared to ansible's YAML/jinja2 configuration.