Name: giddyup
Owner: Rancher
Description: null
Created: 2015-12-03 15:37:35.0
Updated: 2018-04-18 12:29:40.0
Pushed: 2017-08-24 00:03:30.0
Homepage: null
Size: 796
Language: Go
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
Giddyup is a tool to that helps get services started in a Rancher compose stack. It aims to simplify entrypoint and command scripting to start your Docker services. This is a first pass at addressing common tasks when starting up applications in Docker containers on Rancher.
Current capabilities:
in/bash
yup leader check
"$?" -eq "0" ];then
cho "I'm the leader"
This is useful if you need to generate configurations based on all nodes in a service. Otherwise, each container will only get itself and the previous containers metadata.
in/bash
it upto 2 minutes for all containers to come up
ddyup service wait scale --timeout 120
ing up the service
in/bash
ection_string=$(./giddyup ip stringify --suffix :2181 zookeeper/zookeeper)
sults in something like:
.42.231.55:2181,10.42.145.91:2181,10.42.55.78:2181
:
iddyup ip stringify - Prints a joined list of IPs
E:
iddyup ip stringify [command options] [arguments...]
ONS:
-delimiter "," Delimiter to use between entries
-prefix Prepend Entries with this value
-suffix Add this value to the end of each entry.
-source "metadata" Source to lookup IPs. [metadata, dns]
-use-agent-ips Use agent ips instead of rancher ips, only works with metadata source
-use-agent-names Use agent name instead of rancher ips, only works with metadata source
:
iddyup exec - exec out to a command
E:
iddyup exec [command options] [arguments...]
ONS:
-secret-envs reads /run/secrets and sets env vars
-cloud-init Process /self/service/metadata/cloud-init (currently only write_files)
-wait-for-file value wait for a file to exist, assumes something else is creating it. This flag can be used more then once for multiple files
-source-file value Source an environment file before executing. Can use the flag multiple times
example:
ion: '2'
ices:
app:
image: blah
entrypoint: /opt/rancher/bin/giddyup exec --wait-for-file /etc/default/myappenvs --source /etc/default/myappenvs myapp
The --cloud init option looks in the userdefined metadata for cloud-init.write_files. This follows the same syntax as Rancher OS #cloud-init.
ion: '2'
ices:
uentd:
metadata:
cloud-init:
write_files:
- path: /fluentd/etc/fluent.conf
content: |
<source>
@type tail
path /var/lib/docker/containers/*/*-json.log
pos_file /fluentd/log/fluentd-docker.pos
ime_format %Y-%m-%dT%H:%M:%S
tag docker.*
format json
</source>
# Using filter to add container IDs to each event
<filter docker.var.lib.docker.containers.*.*.log>
type record_transformer
<record>
container_id $${tag_parts[5]}
</record>
</filter>
<match **>
@type file
path /fluentd/log/dockerlogs
time_slice_format %Y%m%d
time_slice_wait 10m
time_format %Y%m%dT%H%M%S%z
compress gzip
utc
</match>
In this case, the contents will be placed in /fluentd/etc/fluent.conf
:
iddyup ip myip - Prints the IP of the container
E:
iddyup ip myip
:
iddyup leader - Determines if this container has lowest start index
E:
iddyup leader command [command options] [arguments...]
ANDS:
heck Check if we are leader and exit.
lect Simple leader election with Rancher
orward Listen and forward all port traffic to leader.
et Get the leader of service
elp, h Shows a list of commands or help for one command
ONS:
-help, -h show help
elect and forward are to be used as entrypoints.
If elect is used, only the container determined by Rancher (lowest create_index) will run the service. A command must be given to the elect command to execute if the container becomes the leader. Otherwise all traffic is forwarded to the leader, and upon election the container will exit.
forward should be used in its own container. It works in situations where you want your service running all the time, for replication or something, but want all of the traffic to go to a specific (leader) host.
a forward example:
giddyup leader forward --src-port 3307 --dst-port 3306
This will listen on port 3307 and forward to port 3306 on the leader. This allows you to put a service behind a load balancer, and still have traffic go to one place.
:
iddyup service - Service actions
E:
iddyup service command [command options] [arguments...]
ANDS:
ait Wait for service states
cale Get the set scale of the service
ontainers lists containers in the calling container's service one per line
elp, h Shows a list of commands or help for one command
ONS:
-help, -h show help
scale will give you the set scale of the service, and giddyup service scale –current will give you the current number of containers running in your service.
:
/bin/giddyup health - simple healthcheck
E:
/bin/giddyup health [command options] [arguments...]
ONS:
-listen-port, -p "1620" set port to listen on
-check-command command to execute check
-on-failure-command command to execute if command fails
This check just listens on the port specified (default: 1620) and responds to requests at http://<ip>:<port>/ping and responds with 200 OK. Its meant to be run in a sidekick as the entrypoint. It should share the network namespace as your application.