1
- # Picobot
1
+ # Pico
2
2
3
3
_ The little git robot of automation!_
4
4
5
- [ ![ Build Status] ( https://travis-ci.org/picostack/picobot .svg?branch=master )] ( https://travis-ci.org/picostack/picobot )
5
+ [ ![ Build Status] ( https://travis-ci.org/picostack/pico .svg?branch=master )] ( https://travis-ci.org/picostack/pico )
6
6
7
- Picobot is a git-driven task runner to automate the application of configs.
7
+ Pico is a git-driven task runner to automate the application of configs.
8
8
9
9
## Overview
10
10
11
- Picobot is a little tool for implementing [ Git-Ops] [ git-ops ] in single-server environments. It's analogous to
11
+ Pico is a little tool for implementing [ Git-Ops] [ git-ops ] in single-server environments. It's analogous to
12
12
[ kube-applier] [ kube-applier ] , [ Terraform] [ terraform ] , [ Ansible] [ ansible ] but for automating lone servers that do not
13
13
need cluster-level orchestration.
14
14
15
- Instead, Picobot aims to be extremely simple. You give it some Git repositories and tell it to run commands when those
15
+ Instead, Pico aims to be extremely simple. You give it some Git repositories and tell it to run commands when those
16
16
Git repositories receive commits and that's about it. It also provides a way of safely passing in credentials from
17
17
[ Hashicorp's Vault] [ vault ] .
18
18
@@ -21,16 +21,16 @@ Git repositories receive commits and that's about it. It also provides a way of
21
21
### Linux
22
22
23
23
``` sh
24
- curl -s https://raw.githubusercontent.com/picostack/picobot /master/install.sh | bash
24
+ curl -s https://raw.githubusercontent.com/picostack/pico /master/install.sh | bash
25
25
```
26
26
27
27
Or via Docker:
28
28
29
29
``` sh
30
- docker pull picostack/picobot :v1
30
+ docker pull picostack/pico :v1
31
31
```
32
32
33
- See the docker section below and the image on [ Docker Hub] ( https://hub.docker.com/r/picostack/picobot ) .
33
+ See the docker section below and the image on [ Docker Hub] ( https://hub.docker.com/r/picostack/pico ) .
34
34
35
35
### Everything Else
36
36
@@ -39,22 +39,22 @@ Windows/Mac usage is probably just local testing so just use `go get` for these
39
39
40
40
## Usage
41
41
42
- Currently, Picobot has a single command: ` run ` and it takes a single parameter: a Git URL. This Git URL defines the
43
- "Config Repo" which contains Picobot configuration files. These configuration files declare where Picobot can find
44
- "Target Repos" which are the repos that contain all the stuff you want to automate. The reason Picobot is designed
45
- this way instead of just using the target repos to define what Picobot should do is 1. to consolidate Picobot config
42
+ Currently, Pico has a single command: ` run ` and it takes a single parameter: a Git URL. This Git URL defines the
43
+ "Config Repo" which contains Pico configuration files. These configuration files declare where Pico can find
44
+ "Target Repos" which are the repos that contain all the stuff you want to automate. The reason Pico is designed
45
+ this way instead of just using the target repos to define what Pico should do is 1. to consolidate Pico config
46
46
into one place, 2. separate the config of the tools from the applications and 3. keep your target repos clean.
47
47
48
- Picobot also has a Docker image - see below for docker-specific information.
48
+ Pico also has a Docker image - see below for docker-specific information.
49
49
50
50
### Configuration
51
51
52
- The precursor to Picobot used JSON for configuration, this was fine for simple tasks but the ability to provide a
52
+ The precursor to Pico used JSON for configuration, this was fine for simple tasks but the ability to provide a
53
53
little bit of logic and variables for repetitive configurations is very helpful. Inspired by [ StackExchange's
54
- dnscontrol] [ dnscontrol ] , Picobot uses JavaScript files as configuration. This provides a JSON-like environment with
54
+ dnscontrol] [ dnscontrol ] , Pico uses JavaScript files as configuration. This provides a JSON-like environment with
55
55
the added benefit of conditional logic.
56
56
57
- Here's a simple example of a configuration that should exist in the Picobot config repo that re-deploys a Docker
57
+ Here's a simple example of a configuration that should exist in the Pico config repo that re-deploys a Docker
58
58
Compose stack whenever it changes:
59
59
60
60
``` js
71
71
72
72
The ` T ` function declares a "Target" which is essentially a Git repository. In this example, the repository
73
73
` [email protected] :username/my-docker-compose-project` would contain a
` docker-compose.yml ` file for some application
74
- stack. Every time you make a change to this file and push it, Picobot will pull the new version and run the command
74
+ stack. Every time you make a change to this file and push it, Pico will pull the new version and run the command
75
75
defined in the ` up ` attribute of the target, which is ` docker-compose up -d ` .
76
76
77
77
You can put as many target declarations as you want in the config file, and as many config files as you want in the
@@ -133,23 +133,23 @@ have a bunch of compose configs that all mount data to some path on the machine,
133
133
134
134
See the ` docker-compose.yml ` file for an example and read below for details.
135
135
136
- You can run Picobot as a Docker container. If you're using it to deploy Docker containers via compose, this makes the
137
- most sense. This is quite simple and is best done by writing a Docker Compose configuration for Picobot in order to
136
+ You can run Pico as a Docker container. If you're using it to deploy Docker containers via compose, this makes the
137
+ most sense. This is quite simple and is best done by writing a Docker Compose configuration for Pico in order to
138
138
bootstrap your deployment.
139
139
140
- The Picobot image is built on the ` docker/compose ` image, since most use-cases will use Docker or Compose to deploy
140
+ The Pico image is built on the ` docker/compose ` image, since most use-cases will use Docker or Compose to deploy
141
141
services. This means you must mount the Docker API socket into the container, just like Portainer or cAdvisor or any of
142
142
the other Docker tools that also run inside a container.
143
143
144
144
The socket is located by default at ` /var/run/docker.sock ` and the ` docker/compose ` image expects this path too, so you
145
145
just need to add a volume mount to your compose that specifies ` /var/run/docker.sock:/var/run/docker.sock ` .
146
146
147
- Another minor detail you should know is that Picobot exposes a ` HOSTNAME ` variable for the configuration script.
147
+ Another minor detail you should know is that Pico exposes a ` HOSTNAME ` variable for the configuration script.
148
148
However, when in a container, this hostname is a randomised string such as ` b50fa67783ad ` . This means, if your
149
- configuration performs checks such as ` if (HOSTNAME === 'server031') ` , this won't work. To resolve this, Picobot will
149
+ configuration performs checks such as ` if (HOSTNAME === 'server031') ` , this won't work. To resolve this, Pico will
150
150
attempt to read the environment variable ` HOSTNAME ` and use that instead of using ` /etc/hostname ` .
151
151
152
- This means, you can bootstrap a Picobot deployment with only two variables:
152
+ This means, you can bootstrap a Pico deployment with only two variables:
153
153
154
154
``` env
155
155
VAULT_TOKEN=abcxyz
@@ -158,7 +158,7 @@ HOSTNAME=server012
158
158
159
159
### Docker Compose and ` ./ ` in Container Volume Mounts
160
160
161
- Another caveat to running Picobot in a container to execute ` docker-compose ` is the container filesystem will not
161
+ Another caveat to running Pico in a container to execute ` docker-compose ` is the container filesystem will not
162
162
match the host filesystem paths.
163
163
164
164
If you mount directories from your repository - a common strategy for versioning configuration - ` ./ ` will be expanded
0 commit comments