In a recent blog post I briefly discussed how to build, export and run a service packaged via a Habitat plan.
In this post we will take a look at running Redis and backing it up via Shield.
Running Redis
To play around with the starkandwayne/redis release you can bring it up in the habitat studio:
$ hab studio enter
[1][default:/src:0]# hab svc load starkandwayne/redis
(...)
[2][default:/src:127]# hab pkg binlink starkandwayne/redis [4/1836]
» Symlinking redis-check-rdb from starkandwayne/redis into /bin
★ Binary redis-check-rdb from starkandwayne/redis/3.2.8/20170522110804 symlinked to /bin/redis-check-rdb
» Symlinking redis-server from starkandwayne/redis into /bin
★ Binary redis-server from starkandwayne/redis/3.2.8/20170522110804 symlinked to /bin/redis-server
(...)
[2][default:/src:0]# /bin/redis-cli -a password SET hello world
OK
[3][default:/src:0]# /bin/redis-cli -a password GET hello
"world"
Typing sl will give you the log output of the background supervisor that got started when you entered the studio:
[4][default:/src:0]# sl
--> Tailing the Habitat Supervisor's output (use 'Ctrl+c' to stop)
redis.default(O): | `-._`-._ _.-'_.-' |
redis.default(O): `-._ `-._`-.__.-'_.-' _.-'
redis.default(O): `-._ `-.__.-' _.-'
redis.default(O): `-._ _.-'
redis.default(O): `-.__.-'
redis.default(O):
redis.default(O): 168:M 22 May 13:11:55.082 # Server started, Redis version 3.2.8
redis.default(O): 168:M 22 May 13:11:55.082 * The server is now ready to accept connections on port 6379
(...)
Running Shield daemon
Since Shield is a bit more complex system with a few moving parts I will run it via the pre-exported docker images in docker-compose.
First lets bring up the shield-daemon connected to a database. The daemon is the main coordinator of shield. It triggers backups as needed and persists the state of all created archives and backup jobs.
$ mkdir redis-hab-demo && cd redis-hab-demo $ cat <<EOF > docker-compose.yml
version: '3'
services:
shield:
ports:
- 443:443
image: starkandwayne/shield
command: "start starkandwayne/shield --peer database --bind database:postgresql.shield"
links:
- database
database:
image: starkandwayne/postgresql
command: "start starkandwayne/postgresql --group shield"
EOF
docker-compose up
You can use the shield cli to interact with the daemon. Download it from the github-release.
From another terminal:
$ shield create-backend hab https://localhost
Successfully created backend 'hab', pointing to 'https://localhost'
Using https://localhost (hab) as SHIELD backend
$ export SHIELD_API_TOKEN=autoprovision
To actually backup a system you need to create a few entities in shield such as a policy, schedule and store. Lets create a schedule that takes a backup every day at 4am via the cli:
$ shield create-schedule -k
Schedule Name: daily
Summary:
Time Spec (i.e. 'daily 4am'): daily 4am
Schedule Name: daily
Summary:
Time Spec (i.e. 'daily 4am'): daily 4am
Really create this schedule? [y/n] y
Created new schedule
Name: daily
Summary:
Timespec: daily 4am
$ shield schedules -k
Name Summary Frequency / Interval (UTC)
==== ======= ==========================
daily daily 4am
Because creating all entities manually is error prone we can also automate it by using the shield-agent.
Running Shield agent
The shield-agent is another component of Shield which is typically co-located with the data store you want to backup. You can configure it to automatically provision the elements that shield needs to run a backup.
Stop the docker-compose system via:
docker-compose stop && docker-compose rm -f
Use an EDITOR to add the agent to the docker-compose file. Add the agent service under the already existing services: key:
services:
agent: # to autoprovision the dependant entities
image: starkandwayne/shield-agent
command: "start starkandwayne/shield-agent --bind daemon:shield.default --peer database"
environment:
HAB_SHIELD_AGENT: |
[[stores]]
name='local'
plugin='fs'
[stores.config]
base_dir='/backups'
[schedules]
daily='daily 4am'
[retention-policies]
shortterm='86400'
links:
- database
Bring it up and lets see if it worked:
$ docker-compose up
Once everything is runnin you can see the configured entities in another terminal:
$ shield policies -k
Name Summary Expires in
==== ======= ==========
shortterm 1 days
$ shield stores -k
Name Summary Plugin Configuration
==== ======= ====== =============
local fs {
"base_dir": "/backups"
}
Excellent we have now automatically configured a store. For the demo we are using the fs plugin to store backups in a local folder (/backups). In production you would want to use a plugin that can store the backups on a cloud based object store like s3.
Auto-configuring Redis
Now that we have a schedule, policy and store in place we can bring up Redis and have it automatically configure Shield to run backups.
Again stop the running system:
docker-compose stop && docker-compose rm -f
And add Redis to the docker-compose.yml. Again the redis service belongs under the already existing services: key. The volumes key new:
services:
redis:
image: starkandwayne/redis:edge
volumes:
- backups-volume:/backups
ports:
- 6379:6379
command: "start starkandwayne/redis --peer shield --bind shield:shield.default"
environment:
HAB_REDIS: |
bootstrap_from_backup=true
backups_schedule='daily'
backups_retention='shortterm'
backups_store='local'
links:
- shield
volumes:
backups-volume: {}
Bring it up and have a look:
$ docker-compose up
It can take a while for the whole system to come up but eventually you should see:
% shield jobs -k
Name P? Summary Retention Policy Schedule Remote IP Target
==== == ======= ================ ======== ========= ======
redis-default N shortterm daily 172.27.0.5:5444 {
"base_dir": "/hab/svc/redis/data"
}
So the Redis service we just added was able to configure its own backup job just by binding to a running Shield daemon. Cool!
Lets write a value, take a backup and see if it works:
$ redis-cli -a password SET hello world
OK
$ shield run redis-default -k
Scheduled immediate run of job
To view task, type shield task f82752ae-8066-4bca-9c71-47dc35464c80
$ shield archives -k
UUID Target Restore IP Store Taken at Expires at Status Notes
==== ====== ========== ===== ======== ========== ====== =====
fb2b2b0b-925b-4e69-8083-ab649760048e redis-default (fs) 192.168.16.5:5444 default (fs) Tue, 16 May 2017 13:29:02 +0000 Wed, 17 May 2017 13:29:02 +0000 valid
So we set a value and manually took a backup. Lets destroy and recreate the Redis service. Thanks to the auto-bootstrapping feature the value should be restored without any further input:
$ docker-compose stop redis && docker-compose rm -f redis
Stopping hab_redis_1 ... done
Going to remove hab_redis_1
Removing hab_redis_1 ... done
$ docker-compose up -d redis
hab_database_1 is up-to-date
hab_agent_1 is up-to-date
hab_shield_1 is up-to-date
$ until redis-cli -a password GET hello; do echo 'Waiting for redis to bootstrap'; sleep 1; done
Waiting for redis to bootstrap
Waiting for redis to bootstrap
Waiting for redis to bootstrap
Waiting for redis to bootstrap
"world"
So thanks to Shield and Habitat’s binding feature we are very easily able to add arbitrary Redis services all with backups preconfigured.
Spread the word
