docker_compose_deploy 1.0.0 → 1.1.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: d0c48329c119fc90532529e8a141a52b3cf45b17
-  data.tar.gz: 7489ff60f598b4fe35f69ddf371dc177e1655fed
+  metadata.gz: 0d9dcaa86394d8c24329b214fb239286ff77c0ac
+  data.tar.gz: d7643624e310fbd8305031e50187448a5688fd0b
 SHA512:
-  metadata.gz: c584fece997fe67ba5826b8df74f41c48455d5a6b6feb247f557c32858f5a1ab8072f3974898be0b8d8b9bb249618237b3ff9dea044dcd52f583735a315c69d4
-  data.tar.gz: 8ac15de15749951c7a48b01ae6c3f828df6c20cc564a71d5ca50dad59823da647e895b307a67ced72038e4f17971addab037023df435820b670fa8a77fd68f76
+  metadata.gz: 914b2cb664887b55b8331a0b8d472c7b671b19662d9cafe008b0b00fe9fa93a3f45d78d79a544f105d774d6189ccfe12d1f435a3a43cab875d2597aca484c998
+  data.tar.gz: bb5c8425e50700e879e9b77d5176f744f3b822b79ddea3ab760280017e12be711a15db98e4cf3471f9b7fc08fb1e9d4704f98c326f9e0f2bb4b4916b010437aa

data/README.md

@@ -12,4 +12,141 @@ While these scripts are great for your personal projects, they will not help you
 
 This doesn't provide much over using docker-machine, but it will simplify working with volumes and allow you to test your deployment in a realistic environment.
 
-### The Skeleton
+### The big picture
+
+For my homepage, I serve up multiple applications from the same machine. For this reason, I have nginx to inspect incoming requests and route them to the correct application. As I add new applications, I need to change this setup. So I need to push a new nginx config file as part of my deployment process.
+
+Some of my deployed applications generate data as they run. I want a simple way to download a snapshot of that data as backup. So I want to consolidate all of my data in one place.
+
+While I want to keep the log files that my apps generate, I don't see a need to include those in the backup snapshots that I download. So I want to consolidate my logs somewhere separate from the important data.
+
+DockerComposeDeploy scripts help me:
+
+- push configuration for applications
+- create data and log directories for applications
+- backup data directories
+
+As I add new apps I must update my nginx config. Testing this can be tricky, since nginx will make routing decisions based on the requested url. It's hard to really test this config when everything is hosted on `http://localhost`.  This tool will also:
+
+- Push your project to a vagrant machine
+- Create entries in `/etc/hosts` on the vagrant machine to help you test your nginx config
+
+
+### Installation
+
+```
+gem install 'docker_compose_deploy'
+```
+
+This will add the executable `dcd`
+
+In order to test your project using vagrant, you need to have vagrant installed: https://www.vagrantup.com/
+
+### Creating a new project
+
+We will generate a new project in the 'homepage' directory:
+
+```
+dcd new homepage
+```
+
+You should see the following output:
+
+```
+To see the skeleton app in action, run the following commands
+
+# Move into the directory
+1. cd homepage
+
+# Use vagrant to create the virtual machine for testing (it will open a window and will display Ubuntu's desktop)
+2. vagrant up
+
+# Install docker and docker-compose on the vagrant machine
+3. dcd provision
+
+# Deploy the skeleton app to the vagrant machine
+4. dcd deploy
+
+# See the server in action:
+5. Open firefox on the vagrant machine and visit http://www.test
+```
+
+Follow those steps!  When you visit `www.test` in the vagrant machine, you should see a page that says "site 1 or site 2"
+
+### The Project Structure
+
+Let's investigate each file, one by one.
+
+---
+
+__docker-compose.yml__
+
+A natural place to start to inspect the `docker-compose.yml` file.  You will see three sites defined: proxy, site1, site2.
+
+Each site that is deployed with `dcd` will be provided three directories to mount:
+
+- `./sites/[app_name]/config`: This directory is pushed from your localhost to the remote. Each time you run `dcd deploy` the config directory for each application will be __removed and replaced__ by the directory found on your localhost (if any).  Notice that there is a file on your localhost at `./sites/proxy/config/nginx.conf`. This file will be copied to your host at deployment time.
+
+- `./sites/[app_name]/data`: This directory is the permanent storage for your application. When running `dcd backup`, each application's `data` directory will be zipped up and downloaded for safekeeping.
+
+- `./sites/[app_name]/log`: This directory is for storing logs. It is never removed, but it is also not included in backups. To see what's inside, you'll have to ssh to your server.
+
+Although none of the sites in the skeleton make use of their data directories, the volume maps are included to indicate what mounts are available. Understanding how nginx is configured is beyond the scope of this project, but the configuration found at `./sites/proxy/config/nginx.conf` should be a good template to follow.
+
+---
+
+__config.yml__
+
+This is where we configure what machines `dcd` will connect with. I only need two environments: 'test' and 'production'. The 'test' environment is the vagrant box, the 'production' environment uses my virtual machine on DigitalOcean.
+
+When using the `dcd` command, you can specify the environment using the `-e` flag. If the `-e` is not set, it will default to 'test'. Here is an example:
+
+```
+dcd deploy -e production
+```
+
+You can also configure the `hosts` entry. These will be placed in the `/etc/hosts` file of the remote machine. This is only used on test machines so that we can have fake dns entries. Having these hosts entries allows us to trigger nginx rules that are hard to trigger when using `localhost`. For example:
+```
+server {
+  listen 80;
+  server_name site1.*;
+  ...
+}
+```
+Using a hosts entry allows us to visit `site.test` and trigger that handler.
+
+You can read the comments in `config.yml` for more info.
+
+__Vagrantfile__
+
+Nothing special here. Note that a high port is forwarded to port 22 only to make the configuration for ssh-ing to the machine more predictable.
+
+If you get locked out of your Ubuntu machine the password is `vagrant`.
+
+__ssh_config_overrides__
+
+The Controlmaster stuff at the top helps improve the performance of the multiple ssh commands that are run in quick succession.
+
+The host at the bottom is the connection info for your vagrant machine. If you want to manually ssh to your vagrant machine you can do the following:
+
+```
+vagrant ssh
+```
+or
+
+```
+ssh -F ssh_config_overrides vagrant@default
+```
+
+If `dcd` cannot connect to your vagrant machine, you can run:
+
+```
+vagrant ssh-config >> ssh_config_overrides
+```
+
+This will update the ssh connection info to work with your vagrant machine.
+
+
+### Issues/Questions
+
+If you have any questions or problems using these scripts or somethings just not clear, please open an issue! I'm happy to try to help.

data/lib/docker_compose_deploy/version.rb

@@ -1,3 +1,3 @@
 module DockerComposeDeploy
-  VERSION = "1.0.0"
+  VERSION = "1.1.0"
 end

data/template/Vagrantfile

@@ -1,6 +1,7 @@
 Vagrant.configure("2") do |config|
   config.vm.box = "boxcutter/ubuntu1604-desktop"
   config.vm.network "forwarded_port", guest: 80, host: 8080
+  config.vm.network "forwarded_port", guest: 22, host: 31452
 
   config.vm.provider "virtualbox" do |v|
     v.gui = true

data/template/ssh_config_overrides

@@ -18,7 +18,7 @@ Host *
 Host default
   HostName 127.0.0.1
   User vagrant
-  Port 2222
+  Port 31452
   UserKnownHostsFile /dev/null
   StrictHostKeyChecking no
   PasswordAuthentication no

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: docker_compose_deploy
 version: !ruby/object:Gem::Version
-  version: 1.0.0
+  version: 1.1.0
 platform: ruby
 authors:
 - Pete Kinnecom