4 ms·

The author doesn't give any suggestions for alternative ways to deploy. What are the best practices here? What should operators that currently deploy this way

The author doesn't give any suggestions for alternative ways to deploy. What are the best practices here? What should operators that currently deploy this way do instead?

Hello71 11y ago
http://gitolite.com/deploy.html http://gitolite.com/deploy.html
TheDong 11y ago
The author doesn't need to give such suggestions; that's out of scope of this article. There are many possibilities however. This simplest solution is to add something like ' location ~ /\.git { deny all; }' to your nginx config (or just hide all paths starting with '.'; you rarely want to serve hidden files). The most important practice for remediating this is to have a very clear disconnect between deployment artifacts and development repositories. You want to have your developers write code, and then some preprocessing step to distill that repository into the minimal deployment artifact. This artifact then goes through your integ tests on a gamma stage and onto prod. Whatever deployment system you use should know what git commit this artifact originated from, but the artifact should not have that information on its own. If you want the really poor man's version of this, just have a build system in your repository which populates an "out" directory with everything you actually want to deploy, and then rsync that sucker around. If you want a hip answer to this, Docker has the "Dockerfile" which will specify all artifacts that should be added into it, and should serve as a distillation of what's needed to run your application. I'll point out that this issue won't affect many types of sites in the first place. For example, if you use any sane rails setup, you already have the "public" directory which you use as your static files root, and then you proxy to the unicorn/rack/whatever process which will never serve such files. I would wager that the majority of these sites are poorly configured apache2 + php messes since php made the massive mistake of having the filesystem act as routing; any web framework with good routing (e.g. rails, django, even sinatra, web.py) will not suffer from this without going out of your way a bit.
orik 11y ago
599 out of every 600 sites don't have the problem of a public facing .git folder. I don't think alternative deployments need to be suggested as they are commonplace. It depends on what sort of platform and server you're running on but just do what you have to do so you're not serving your .git.
- ludamad 11y ago
  Doesn't change anything, but worth noting, these are not necessarily 599 git-using websites being compared.
swang 11y ago
Besides what TheDong has suggested (hiding your .git folder from public view), you could also have a build server that in the end tarballs everything up and deploys it onto your live servers.
- TheDong 11y ago
  Perhaps you didn't read my response fully; after the initial 'simple solution', having a deployment artifact is exactly what I suggest.
  - swang 11y ago
    Eh yep you're right. Should have read slower.
2ion 11y ago
I simply use a 'checkout' process where all website assets to be deployed are copied into for example a /dst folder and the folder then rsync'd to the webroot (with rsync -ru --delete --chmod). This avoids clutter and still allows to just update changed files. The actual page source is still under git.
slackmeister 11y ago
You can use git-archive (http://git-scm.com/docs/git-archive http://git-scm.com/docs/git-archive , examples provided at the bottom)
InclinedPlane 11y ago
I use a separate work folder. Like this: git --git-dir=/foo/bar.git --work-tree=/foo/bar.work init git --git-dir=/foo/bar.git config receive.denyCurrentBranch ignore Then create (and chmod +x): /foo/bar.git/hooks/post-update #!/bin/sh work_tree=/foo/bar.work GIT_WORK_TREE=$work_tree git checkout -f Then you just create a symlink to the work tree for your website root, or put the work tree there, or whatever, depending on preference. Can't say this is perfect, but it works pretty well for smaller projects.
shkkmo 11y ago
I personally prefer to have my web directory be a sub folder of the project root. This not only solves issues with .git directory be accessible but also helps prevent gotchas with exposing documentation or other data not intended for public consumption.
sago 11y ago
For fairly modest sites or projects 1. Configure your webserver to hide common directories and files. 2. Don't store passwords / credentials in version control. 2a. If you use a test suite, add a test to verify this. 3. Have a make step that builds the deployment content into a separate directory. (e.g. a gulp deploy task) 4. Rsync the deploy content to your destination server. Instead of 4, more complex systems (with multiple servers, libraries, etc) use Docker to build an image from your deloy content.
chei0aiV 11y ago
Personally I would use standard practices of the open source world; package your app properly into a .deb/.rpm, deploy that and push configuration for it out using puppet/ansible/etc. aka, debops! https://enricozini.org/2014/debian/debops/ https://enricozini.org/2014/debian/debops/
- rurounijones 11y ago
  I would dispute the idea that packaging your web-app (which is what the article is talking about) into a .deb or .rpm is a standard practice.
Spidler 11y ago
We deploy from git via "git archive". Wastes a bit of space, but there's no extra resources on the server.

The author doesn't give any suggestions for alternative ways to deploy. What are the best practices here? What should operators that currently deploy this way do instead?

Hello71 11y ago

http://gitolite.com/deploy.html http://gitolite.com/deploy.html

TheDong 11y ago

The author doesn't need to give such suggestions; that's out of scope of this article. There are many possibilities however. This simplest solution is to add something like ' location ~ /\.git { deny all; }' to your nginx config (or just hide all paths starting with '.'; you rarely want to serve hidden files). The most important practice for remediating this is to have a very clear disconnect between deployment artifacts and development repositories. You want to have your developers write code, and then some preprocessing step to distill that repository into the minimal deployment artifact. This artifact then goes through your integ tests on a gamma stage and onto prod. Whatever deployment system you use should know what git commit this artifact originated from, but the artifact should not have that information on its own. If you want the really poor man's version of this, just have a build system in your repository which populates an "out" directory with everything you actually want to deploy, and then rsync that sucker around. If you want a hip answer to this, Docker has the "Dockerfile" which will specify all artifacts that should be added into it, and should serve as a distillation of what's needed to run your application. I'll point out that this issue won't affect many types of sites in the first place. For example, if you use any sane rails setup, you already have the "public" directory which you use as your static files root, and then you proxy to the unicorn/rack/whatever process which will never serve such files. I would wager that the majority of these sites are poorly configured apache2 + php messes since php made the massive mistake of having the filesystem act as routing; any web framework with good routing (e.g. rails, django, even sinatra, web.py) will not suffer from this without going out of your way a bit.

orik 11y ago

599 out of every 600 sites don't have the problem of a public facing .git folder. I don't think alternative deployments need to be suggested as they are commonplace. It depends on what sort of platform and server you're running on but just do what you have to do so you're not serving your .git.

ludamad 11y ago
Doesn't change anything, but worth noting, these are not necessarily 599 git-using websites being compared.

swang 11y ago

Besides what TheDong has suggested (hiding your .git folder from public view), you could also have a build server that in the end tarballs everything up and deploys it onto your live servers.

TheDong 11y ago
Perhaps you didn't read my response fully; after the initial 'simple solution', having a deployment artifact is exactly what I suggest.
- swang 11y ago
  Eh yep you're right. Should have read slower.

2ion 11y ago

I simply use a 'checkout' process where all website assets to be deployed are copied into for example a /dst folder and the folder then rsync'd to the webroot (with rsync -ru --delete --chmod). This avoids clutter and still allows to just update changed files. The actual page source is still under git.

slackmeister 11y ago

You can use git-archive (http://git-scm.com/docs/git-archive http://git-scm.com/docs/git-archive , examples provided at the bottom)

InclinedPlane 11y ago

I use a separate work folder. Like this: git --git-dir=/foo/bar.git --work-tree=/foo/bar.work init git --git-dir=/foo/bar.git config receive.denyCurrentBranch ignore Then create (and chmod +x): /foo/bar.git/hooks/post-update #!/bin/sh work_tree=/foo/bar.work GIT_WORK_TREE=$work_tree git checkout -f Then you just create a symlink to the work tree for your website root, or put the work tree there, or whatever, depending on preference. Can't say this is perfect, but it works pretty well for smaller projects.

shkkmo 11y ago

I personally prefer to have my web directory be a sub folder of the project root. This not only solves issues with .git directory be accessible but also helps prevent gotchas with exposing documentation or other data not intended for public consumption.

sago 11y ago

For fairly modest sites or projects 1. Configure your webserver to hide common directories and files. 2. Don't store passwords / credentials in version control. 2a. If you use a test suite, add a test to verify this. 3. Have a make step that builds the deployment content into a separate directory. (e.g. a gulp deploy task) 4. Rsync the deploy content to your destination server. Instead of 4, more complex systems (with multiple servers, libraries, etc) use Docker to build an image from your deloy content.

chei0aiV 11y ago

Personally I would use standard practices of the open source world; package your app properly into a .deb/.rpm, deploy that and push configuration for it out using puppet/ansible/etc. aka, debops! https://enricozini.org/2014/debian/debops/ https://enricozini.org/2014/debian/debops/

rurounijones 11y ago
I would dispute the idea that packaging your web-app (which is what the article is talking about) into a .deb or .rpm is a standard practice.

Spidler 11y ago

We deploy from git via "git archive". Wastes a bit of space, but there's no extra resources on the server.