3 ms·

> When deploying a web application, some administrators simply clone the repository. Step one: stop randomly smearing crap around. Prod should only have files

> When deploying a web application, some administrators simply clone the repository. Step one: stop randomly smearing crap around. Prod should only have files that came from a .deb or .rpm signed by the legit build process, because that's how you know your system is reproducible and has everything it should and nothing else.

marcosdumay 9y ago
And then you moved the problem from keeping your files in sync on the web server to keeping your files in sync on the package source.
- stephenr 9y ago
  Building debs and rpms from version control is a legitimate step though.
- eropple 9y ago
  That's a significantly more straightforward and safer problem to have to handle. You should prefer it across-the-board.
  - marcosdumay 9y ago
    That's the exactly same problem, with the exactly same failure modes and consequences on failure. It's also solved the exact same ways, by scripting your stuff on one level or another.
    - eropple 9y ago
      Solving the problem in one place (your CI/CD server) is a significantly less complex a task than solving it in N places (every server on which your application is running). It removes the concerns around configuration drift (have all your machines been properly brought up to policy?) and enables easier reasoning about the whole thing.
jdwithit 9y ago
Yes, this. Cloning a git repo is not a reproducible build and deploy strategy, especially once you scale past one developer. Building a package (RPM/DEB/Docker container/whatever) once, and promoting it from dev through to test and prod, is. You are guaranteeing that the same code you wrote and tested is what is finally being deployed to production. If the deploy process is "git pull", you're praying that Joe McGee didn't push some untested crap to the relevant branch 5 seconds before you deployed. I'll argue with "that's how you know your system is reproducible and has everything it should and nothing else", though. To get there, you need to look at immutable infrastructure, where you're building a new container or VM image for every deploy. Otherwise you might have libfoo installed on the app server, despite your app dropping support for foo 2 years ago.
- Twisell 9y ago
  This is yet another problem. Joe McGee shouldn't be able to push in your master branch anyway. You can use git for deployment but indeed you must have a clear commit policy to do that (and it's a good idea anyway to push only major curated versions on master).
falsedan 9y ago
Woah, that's not very kind! Some of these sites are run on a shoestring by sysadmins who are also juggling other issues, and it's hard for them to justify a brand-new deployment pipeline when the existing 'fput ~/code/the_web_site ftp://hosting/our_great_web_site' deployment costs nothing to maintain and works fine (sales/conversions are coming in).
kuschku 9y ago
Not necessarily. You can actually use git in production, properly. I personally like to mount gitRepo volumes on Kubernetes, and have my CI pipeline automatically update the revision of the deployment whenever it validates tests. Then I have kubernetes roll out the update automatically.

marcosdumay 9y ago

And then you moved the problem from keeping your files in sync on the web server to keeping your files in sync on the package source.

stephenr 9y ago
Building debs and rpms from version control is a legitimate step though.
eropple 9y ago
That's a significantly more straightforward and safer problem to have to handle. You should prefer it across-the-board.
- marcosdumay 9y ago
  That's the exactly same problem, with the exactly same failure modes and consequences on failure. It's also solved the exact same ways, by scripting your stuff on one level or another.
  - eropple 9y ago
    Solving the problem in one place (your CI/CD server) is a significantly less complex a task than solving it in N places (every server on which your application is running). It removes the concerns around configuration drift (have all your machines been properly brought up to policy?) and enables easier reasoning about the whole thing.

jdwithit 9y ago

Yes, this. Cloning a git repo is not a reproducible build and deploy strategy, especially once you scale past one developer. Building a package (RPM/DEB/Docker container/whatever) once, and promoting it from dev through to test and prod, is. You are guaranteeing that the same code you wrote and tested is what is finally being deployed to production. If the deploy process is "git pull", you're praying that Joe McGee didn't push some untested crap to the relevant branch 5 seconds before you deployed. I'll argue with "that's how you know your system is reproducible and has everything it should and nothing else", though. To get there, you need to look at immutable infrastructure, where you're building a new container or VM image for every deploy. Otherwise you might have libfoo installed on the app server, despite your app dropping support for foo 2 years ago.

Twisell 9y ago
This is yet another problem. Joe McGee shouldn't be able to push in your master branch anyway. You can use git for deployment but indeed you must have a clear commit policy to do that (and it's a good idea anyway to push only major curated versions on master).

falsedan 9y ago

Woah, that's not very kind! Some of these sites are run on a shoestring by sysadmins who are also juggling other issues, and it's hard for them to justify a brand-new deployment pipeline when the existing 'fput ~/code/the_web_site ftp://hosting/our_great_web_site' deployment costs nothing to maintain and works fine (sales/conversions are coming in).

kuschku 9y ago

Not necessarily. You can actually use git in production, properly. I personally like to mount gitRepo volumes on Kubernetes, and have my CI pipeline automatically update the revision of the deployment whenever it validates tests. Then I have kubernetes roll out the update automatically.