N.B.: the active maintenance fork of this project is available at https://github.com/steamhaus/goat
goat is a Go program which runs from inside the EC2 instance.
By setting your tags correctly, goat can discover and attach EBS volumes and ENIs. For EBS volumes, it can perform additional actions such as RAID (with mdadm), mkfs, and mount EBS volumes to the EC2 instance where it's running.
Goat is a Go binary that should be able to run on any Linux instance. In the releases tab you can find a zip of the binary, and a .deb and .rpm package with systemd support. Goat needs mdadm to perform RAID (which is a dependency in the deb and rpm).
To use goat, run it during the launch process of your EC2 instance - you can systemctl enable goat@TARGET and systemctl start goat@TARGET (where TARGET is one of ebs or eni) in the EC2 user data script. Full Terraform example here.
In the most basic case, you should run goat ebs or goat eni.
Full usage:
Usage: goat [OPTIONS] ebs|eni
OPTIONS
-debug
Interactive debug prompts
-logLevel string
Log level (default "info")
-tagPrefix string
Prefix for GOAT related tags (default "GOAT-IN")
-version
Display version and exit
You can set -tagPrefix and -logLevel with environment variables (which take precedence):
GOAT_LOG_LEVELGOAT_TAG_PREFIX
These are the tags you need (recall that the GOAT-IN prefix is configurable):
| Tag Name | Description | Resource type | Required | Effect |
|---|---|---|---|---|
| GOAT-IN:Prefix | Logical app name | EC2, EBS, ENI | ✔️ | attach |
| GOAT-IN:NodeId | Node id | EC2, EBS, ENI | ✔️ | attach |
| GOAT-IN:VolumeName | Distinct volume name | EBS | ||
| GOAT-IN:VolumeSize | # of disks in vol group | EBS | mdadm | |
| GOAT-IN:RaidLevel | level of RAID (0 or 1) | EBS | mdadm | |
| GOAT-IN:MountPath | Linux path to mount vol | EBS | mount | |
| GOAT-IN:FsType | Linux filesystem type | EBS | mkfs |
If non-required tags are omitted, that step is skipped. The barest case will simply attach the EBS volumes and perform no further actions.
The filesystem and fstab entries are created with the label GOAT-{VolumeName} for convenience. Running goat multiple times will result in it detecting the existing label it intended to create and not proceeding.
Aside from the mount syscall, goat shells out to mdadm, blkid, and mkfs. If the mount and RAID steps are performed, the configs will be persisted to /etc/fstab and /etc/mdadm.conf.
Check the Terraform example for example tag values.
It's necessary for the instance to have an IAM Role with at least access to the EBS and ENI resources that it will be attaching - see here. Your roles can be even more permissive (i.e. full EC2 access) but that comes with its own risks.
Unfortunately, resource-level permissions are currently not supported for attaching network interfaces. This means that to use goat@eni, your instances must have full permissions for all ENIs.
The specific use-case that goat was developed to solve is the following. Say you have 3 instances with their own respective disks, and you receive a termination notice for instance 1. I want the goat workflow to be:
- Terminate instance 1
- Create a new instance with the same GOAT tags (to indicate to
goatthat it's the logical equivalent as the machine it is replacing)- No need to modify or manipulate the EBS volumes or their tags
- On boot, everything works magically
After goat ran on the first fresh run, the EBS volumes got the correct filesystems, labels, and in the case of RAID, mdadm metadata on them.
The event flow on a re-created instance is:
- Get EC2 metadata on the running instance, create an EC2 client, and search EBS volumes
- Attach the volumes it needs based on their tags
- Discover that
/dev/disk/by-labelalready contains the correct disks- From
mdadmmagic, after the EBS attachment the RAID array is already detected correctly
- From
- Proceed to perform the
fstabandmountphases - skipmdadm,mkfs
CAVEAT: the mdadm metadata will have the hostname of the previous EC2 instance:
[centos@ip-172-31-29-69 ~]$ sudo mdadm --detail --scan --verbose
ARRAY /dev/md127 level=raid0 num-devices=3 metadata=1.2 name="ip-172-31-25-105:'GOAT-data'" UUID=2d08b310:fd13bd21:bc2417a4:56a1ec57
devices=/dev/xvdb,/dev/xvdc,/dev/xvdd
[centos@ip-172-31-29-69 ~]$
To avoid this, define a good/persistent hostname for the EC2 instance, that you will then re-apply to any instance taking ownership of the previous instance's disks.
As mentioned, the only action goat will do for ENIs is attaching them. You can try to use ec2-net-utils, a tool available on Amazon Linux AMIs, or this port to CentOS/systemd, to configure an ENI after goat attaches it.
ENI attachments take a parameter called DeviceIndex. Goat isn't smart, and always starts from DeviceIndex 1. This means that your EC2 instance should have no attached ENIs to use goat. If it does, they should be the ones that goat was going to attach anyway, not external ENIs that have no goat tags.
The deb, rpm, and zip are generated from a multi-stage Dockerfile.build. Invoke it with make docker-build. If you have docker locally, you can use the following command in order to quickly get a development env ready: make dev-env.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent