<commit_before>## coreinit - a distributed init system.

coreinit ties together [systemd](http://coreos.com/using-coreos/systemd) and [etcd](https://github.com/coreos/etcd) into a distributed init system. Think of it as an extension of systemd that operates at the cluster level instead of the machine level.

This project is very low level and is designed as a foundation for higher order orchestration.

[![Build Status](https://travis-ci.org/coreos/coreinit.png?branch=master)](https://travis-ci.org/coreos/coreinit)

### Set Up

coreinit needs to be running on each machine that's part of the cluster. On a CoreOS machine, drop in a coreinit unit file and start it. You can configure coreinit to talk to a local etcd endpoint (default) or a remote cluster.

### Writing Unit Files

Coreinit schedules each unit file to a machine in the cluster, taking into account a few special properties under the `X-Coreinit` section. 

| Property Name | Description |
|---------------|-------------|
| X-Coreinit-Provides | A string that represents the service name. This is used to enforce `X-Coreinit-MachineSingleton`. |
| X-Coreinit-Peers | The name of a unit file that should be scheduled alongside this unit. |
| X-Coreinit-MachineSingleton | Boolean value that controls whether multiple copies of this service can run on a single machine. Useful for creating HA services. |

To deploy multiple copies of a service, generate unique copies of each unit file. Each will need its own name (`apache1.service`) and contents where appropriate. In the following example, the name of the container `apache1` is unique. These unit files should be considered perfectly cachable. Any changes will need to result in a new unit file.

```
[Unit]
Description=Example service started with coreinit
After=docker.service

[Service]
ExecStart=/usr/bin/docker run -name apache1 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND
ExecStop=/usr/bin/docker stop apache1

[X-Coreinit]
X-Coreinit-Provides=apache<commit_msg>fix(readme): expand build and set up instructions<commit_after>## coreinit - a distributed init system.

coreinit ties together [systemd](http://coreos.com/using-coreos/systemd) and [etcd](https://github.com/coreos/etcd) into a distributed init system. Think of it as an extension of systemd that operates at the cluster level instead of the machine level.

This project is very low level and is designed as a foundation for higher order orchestration.

[![Build Status](https://travis-ci.org/coreos/coreinit.png?branch=master)](https://travis-ci.org/coreos/coreinit)

### Building

Coreinit must be built with Go 1.2 on a Linux machine, or in a [Go docker container](https://index.docker.io/u/miksago/ubuntu-go/). Simply run `./build` and then copy the binaries onto each of your machines.

### Set Up

coreinit needs to be running on each machine that's part of the cluster. On each CoreOS machine, place the `coreinit` and `corectl` binaries in `/home/core`, the unit into `/media/state/units/coreinit.service`, and the config file into `/home/core/coreinit.conf`.

```
$ cat /media/state/units/coreinit.service
[Unit]
Description=coreinit

[Service]
ExecStart=/home/core/coreinit -config_file /home/core/coreinit.conf
```

You can configure coreinit to talk to a local etcd endpoint (default) or a remote cluster with `etcd_servers` in your config file:

```
$ cat /home/core/coreinit.conf
verbosity=1
etcd_servers=["http://PRIVATE_IP:4001"] # optional
```

To start your coreinit unit, run `sudo systemctl start coreinit.service`.

### Writing Unit Files

Coreinit schedules each unit file to a machine in the cluster, taking into account a few special properties under the `X-Coreinit` section. 

| Property Name | Description |
|---------------|-------------|
| X-Coreinit-Provides | A string that represents the service name. This is used to enforce `X-Coreinit-MachineSingleton`. |
| X-Coreinit-Peers | The name of a unit file that should be scheduled alongside this unit. |
| X-Coreinit-MachineSingleton | Boolean value that controls whether multiple copies of this service can run on a single machine. Useful for creating HA services. |

To deploy multiple copies of a service, generate unique copies of each unit file. Each will need its own name (`apache1.service`) and contents where appropriate. In the following example, the name of the container `apache1` is unique. These unit files should be considered perfectly cachable. Any changes will need to result in a new unit file.

```
[Unit]
Description=Example service started with coreinit
After=docker.service

[Service]
ExecStart=/usr/bin/docker run -name apache1 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND
ExecStop=/usr/bin/docker stop apache1

[X-Coreinit]
X-Coreinit-Provides=apache
{'fraction_non_alphanumeric': 0.09674027339642481, 'fraction_numerical': 0.0035751840168243955, 'mean_word_length': 4.319910514541387, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 7, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7499331', 'n_tokens_mistral': 1334, 'n_tokens_neox': 1289, 'n_words': 580}