Question

I'd like to run/host specific branches of a project's Git repository on separate vhosts/domains for testing/preview purposes. I'm thinking about a process which would deploy a branch, after a Git push, to a "preview" or "testing" server for manual testing in a browser.

E.g. it would be nice to have a branch called "feature/my-new-feature" deployed to a specific server and have the project accessible on an URL like "my-new feature.project.com".

The problems I face (theoretically, in the first place) are mostly challenges about database connectivity/configuration, ports, etc. For example, if there are multiple branches running on separate subdomains on a single server, they would need to share a single MySQL installation - but in reality every branch would need it's own, separate MySQL instance, because the database configuration doesn't change for all the branches, which means they connect to the same host and use the same database name, user, etc.

One way probably would be to run a VM for every branch on it's own subdomain, mapping the ports directly to the VM (at least I think that's possible somehow), but for many projects with many branches this would mean I need a lot of hardware power to handle this. (And probably also a lot of money.)

Then I heard about docker and/or Linux containers and thought maybe this could work out but I'm not entirely sure how and if it works at all.

I'm wondering what the established ways of running multple versions of a project in parallel without problems of interfering services and related conflicts are.

Would it be possible to use docker for such a setup or is this the totally wrong direction I'm heading?

Thanks a lot for your anwsers.

Était-ce utile?

La solution

Your question scope is rather large.

About wether linux containers and docker are usable for what you have in mind: yes, definitely. Containers are lightweight and cheap to deploy (way cheaper than VM), and using containers for continuous deployment / parallel testing does work very well.

Now, here is how docker works: you create a dockerfile that describes what services your application requires inside the container (mysql, php, whatever), what specific tuning / setup on the container OS you need, and where to put your application code. Then you create an "image" from that dockerfile, finally start a new container from that image, and that container will be entirely standalone, providing a "clean room" context for your application to execute.

The container has a specific ip, and will expose the services you choose on it. These services will then be NATed onto the host (you might even choose on which port at start time). Then it's rather simple to reverse proxy these using nginx so to serve these containers from various domain names / urls.

You can learn about dockerfile (and docker generally) here: http://docs.docker.io/en/latest/

If I were indeed to test branches that way, I would:

  • write a Dockerfile describing my application stack, and push it on every branch of my project
  • use a CI tool (jenkins, strider, whatever) and have it hooked into github so that it would build a new image on every pushed commit (docker build -rm -t me/myproject:branchname), and then stop the previously running container for that branch, and start a new container from the newly built image (assuming the build succeeded)
  • setup my host nginx as a reverse proxy, mapping, say http://example/branch to http://localhost:NATTED_PORT/

Note that Hipache (https://github.com/dotcloud/hipache) might be an alternative to fiddling with nginx as a proxy though I have no first hand experience with it.

This is a rough description of the steps involved, and you probably have some learning to do, but that should put you on track I hope.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top