ufo 1.6.1 → 1.6.2
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/CHANGELOG.md +5 -0
- data/README.md +25 -260
- data/docs/_docs/automated-cleanup.md +15 -0
- data/docs/_docs/conventions.md +3 -4
- data/docs/_docs/helpers.md +22 -0
- data/docs/_docs/install.md +6 -1
- data/docs/_docs/migrations.md +32 -0
- data/docs/_docs/next-steps.md +1 -1
- data/docs/_docs/run-in-pieces.md +30 -0
- data/docs/_docs/{ufo-settings.md → settings.md} +1 -1
- data/docs/_docs/single-task.md +29 -0
- data/docs/_docs/tutorial-ufo-docker-build.md +2 -2
- data/docs/_docs/tutorial-ufo-init.md +27 -2
- data/docs/_docs/tutorial-ufo-ship.md +30 -1
- data/docs/_docs/tutorial-ufo-ships.md +13 -4
- data/docs/_docs/tutorial-ufo-tasks-build.md +14 -6
- data/docs/_docs/ufo-destroy.md +0 -1
- data/docs/_docs/ufo-help.md +1 -1
- data/docs/_docs/ufo-scale.md +1 -0
- data/docs/_docs/ufo-tasks-register.md +1 -1
- data/docs/_includes/contact.html +1 -1
- data/docs/_includes/footer.html +2 -1
- data/docs/_includes/subnav.html +7 -2
- data/docs/_includes/ufo-ship-options.md +1 -1
- data/docs/quick-start.md +1 -1
- data/lib/starter_project/bin/deploy +2 -7
- data/lib/starter_project/ufo/settings.yml +3 -3
- data/lib/ufo/cli/help.rb +1 -1
- data/lib/ufo/version.rb +1 -1
- metadata +8 -3
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 719240a41b0030380ceb747403c3fb272120a9be
|
4
|
+
data.tar.gz: 8238a183e5602cc44f7681091a9bb823541f3ec5
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 5aa712d256743f80d959653230cfc4f5542ff98aa315ea33012c4e93ac4810206dee120ac39c9c4b26c5ce0957e5d6126915813d46e153405d36684c8004d003
|
7
|
+
data.tar.gz: 9e4707e07e52225a45f378a8f358d8033de2b39298b1014d03ebbd2b941ee157789ab28c8286dea1b77994e71a6f7dffb1ca4db5c974113443649080cc016f91
|
data/CHANGELOG.md
CHANGED
@@ -3,6 +3,11 @@
|
|
3
3
|
All notable changes to this project will be documented in this file.
|
4
4
|
This project *tries* to adhere to [Semantic Versioning](http://semver.org/), even before v1.0.
|
5
5
|
|
6
|
+
## [1.6.2]
|
7
|
+
* update bin/deploy starter project script
|
8
|
+
* update help menu
|
9
|
+
* update docs
|
10
|
+
|
6
11
|
## [1.6.1]
|
7
12
|
* exit if docker push fails
|
8
13
|
|
data/README.md
CHANGED
@@ -1,291 +1,56 @@
|
|
1
|
-
# Ufo -
|
1
|
+
# Ufo - Easy Way to Build and Ship Docker to AWS ECS
|
2
2
|
|
3
3
|
[![CircleCI](https://circleci.com/gh/tongueroo/ufo.svg?style=svg)](https://circleci.com/gh/tongueroo/ufo)
|
4
4
|
|
5
|
-
|
5
|
+
Ufo is a tool that makes building and shipping Docker images to [AWS ECS](https://aws.amazon.com/ecs/) super easy.
|
6
6
|
|
7
|
-
|
8
|
-
|
9
|
-
* This blog post provides an introduction to the tool: [Ufo - Build Docker Containers and Ship Them to AWS ECS](https://medium.com/@tongueroo/ufo-easily-build-docker-containers-and-ship-them-to-aws-ecs-15556a2b39f#.qqu8o4wal).
|
10
|
-
* This presentation covers ufo also: [Ufo Ship on AWS ECS](http://www.slideshare.net/tongueroo/ufo-ship-for-aws-ecs-70885296)
|
11
|
-
|
12
|
-
A summary of what `ufo ship` does:
|
7
|
+
The main command is `ufo ship`. Here's summary of what it does:
|
13
8
|
|
14
9
|
1. Builds a docker image.
|
15
10
|
2. Generates and registers the ECS template definition.
|
16
|
-
3. Deploys the ECS template definition to the
|
11
|
+
3. Deploys the ECS template definition to the ECS service.
|
17
12
|
|
18
|
-
Ufo deploys a task definition that is
|
13
|
+
Ufo deploys a task definition that is written in a templating language that is easily and fully controllable.
|
19
14
|
|
15
|
+
See [ufoships.com](http://ufoships.com) for full documentation.
|
20
16
|
|
21
17
|
## Installation
|
22
18
|
|
23
|
-
|
24
|
-
|
25
|
-
### Dependencies
|
26
|
-
|
27
|
-
* Docker: You will need a working version of [Docker](https://docs.docker.com/engine/installation/) installed as ufo shells out and calls the `docker` command.
|
28
|
-
* AWS: Set up your AWS credentials at `~/.aws/credentials` and `~/.aws/config`. This is the [AWS standard way of setting up credentials](https://aws.amazon.com/blogs/security/a-new-and-standardized-way-to-manage-credentials-in-the-aws-sdks/).
|
29
|
-
|
30
|
-
## Quick Usage
|
31
|
-
|
32
|
-
### ufo ship
|
33
|
-
|
34
|
-
To execute the ship process run:
|
35
|
-
|
36
|
-
```bash
|
37
|
-
ufo ship hi-web-prod --cluster mycluster
|
38
|
-
```
|
39
|
-
|
40
|
-
Note, if you have configured `ufo/settings.yml` to map hi-web-prod to the `mycluster` cluster using the service_cluster option the command becomes simply:
|
41
|
-
|
42
|
-
```bash
|
43
|
-
ufo ship hi-web-prod
|
44
|
-
```
|
45
|
-
|
46
|
-
When you run `ufo ship hi-web-prod`:
|
47
|
-
|
48
|
-
1. It builds the docker image.
|
49
|
-
2. Generates a task definition and registers it.
|
50
|
-
3. Updates the ECS service to use it.
|
51
|
-
|
52
|
-
If the ECS service hi-web-prod does not yet exist, ufo will create the service for you.
|
53
|
-
|
54
|
-
By convention, if the service has a container name web, you'll get prompted to create an ELB and specify a target group arn. The ELB and target group must already exist.
|
55
|
-
|
56
|
-
You can bypass the prompt and specify the target group arn as part of the command. The elb target group can only be associated when the service gets created for the first time. If the service already exists then the `--target-group` parameter just gets ignored and the ECS task simply gets updated. Example:
|
57
|
-
|
58
|
-
|
59
|
-
```bash
|
60
|
-
ufo ship hi-web-prod --target-group=arn:aws:elasticloadbalancing:us-east-1:12345689:targetgroup/hi-web-prod/12345
|
61
|
-
```
|
62
|
-
|
63
|
-
When using ufo if the ECS service does not yet exist, it will automatically be created for you. Ufo will also automatically create the ECS cluster. If you are relying on this tool to create the cluster, you still need to associate ECS Container Instances to the cluster yourself.
|
64
|
-
|
65
|
-
## Detailed Usage
|
66
|
-
|
67
|
-
First initialize ufo files within your project. Let's say you have an example `hi` app.
|
68
|
-
|
69
|
-
```
|
70
|
-
$ git clone https://github.com/tongueroo/hi
|
71
|
-
$ cd hi
|
72
|
-
$ ufo init --app hi --cluster stag --image tongueroo/hi
|
73
|
-
Setting up ufo project...
|
74
|
-
created: ./bin/deploy
|
75
|
-
exists: ./Dockerfile
|
76
|
-
created: ./ufo/settings.yml
|
77
|
-
created: ./ufo/task_definitions.rb
|
78
|
-
created: ./ufo/templates/main.json.erb
|
79
|
-
created: ./.env
|
80
|
-
Starter ufo files created.
|
81
|
-
$
|
82
|
-
```
|
83
|
-
|
84
|
-
Take a look at the `ufo/settings.yml` file and notice that it contains some default configuration settings so you do not have to type out these options repeatedly for some of the ufo commands.
|
85
|
-
|
86
|
-
```yaml
|
87
|
-
image: tongueroo/hi
|
88
|
-
service_cluster:
|
89
|
-
default: prod # default cluster
|
90
|
-
hi-web-prod: blue
|
91
|
-
hi-clock-prod: blue
|
92
|
-
hi-worker-prod: blue
|
93
|
-
```
|
94
|
-
|
95
|
-
The `image` value is the name that ufo will use for the Docker image name.
|
96
|
-
|
97
|
-
The `service_cluster` mapping provides a way to set default service-to-cluster mappings so that you do not have to specify the `--cluster` repeatedly. This is very helpful. For example:
|
98
|
-
|
99
|
-
```
|
100
|
-
ufo ship hi-web-prod --cluster hi-cluster
|
101
|
-
ufo ship hi-web-prod # same as above because it is configured in ufo/settings.yml
|
102
|
-
ufo ship hi-web-prod --cluster special-cluster # overrides the default setting in `ufo/settings.yml`.
|
103
|
-
```
|
104
|
-
|
105
|
-
### Task Definition ERB Template and DSL Generator
|
106
|
-
|
107
|
-
Ufo task definitions are written as an ERB template that makes it every easily accessible and configurable to your requirements. Here is is an example of an ERB template `ufo/templates/main.json.erb` that shows how easy it is to modfied the task definition you want to be uploaded by ufo:
|
108
|
-
|
109
|
-
```json
|
110
|
-
{
|
111
|
-
"family": "<%= @family %>",
|
112
|
-
"containerDefinitions": [
|
113
|
-
{
|
114
|
-
"name": "<%= @name %>",
|
115
|
-
"image": "<%= @image %>",
|
116
|
-
"cpu": <%= @cpu %>,
|
117
|
-
<% if @memory %>
|
118
|
-
"memory": <%= @memory %>,
|
119
|
-
<% end %>
|
120
|
-
<% if @memory_reservation %>
|
121
|
-
"memoryReservation": <%= @memory_reservation %>,
|
122
|
-
<% end %>
|
123
|
-
<% if @container_port %>
|
124
|
-
"portMappings": [
|
125
|
-
{
|
126
|
-
"containerPort": "<%= @container_port %>",
|
127
|
-
"protocol": "tcp"
|
128
|
-
}
|
129
|
-
],
|
130
|
-
<% end %>
|
131
|
-
"command": <%= @command.to_json %>,
|
132
|
-
<% if @environment %>
|
133
|
-
"environment": <%= @environment.to_json %>,
|
134
|
-
<% end %>
|
135
|
-
<% if @awslogs_group %>
|
136
|
-
"logConfiguration": {
|
137
|
-
"logDriver": "awslogs",
|
138
|
-
"options": {
|
139
|
-
"awslogs-group": "<%= @awslogs_group %>",
|
140
|
-
"awslogs-region": "<%= @awslogs_region || 'us-east-1' %>",
|
141
|
-
"awslogs-stream-prefix": "<%= @awslogs_stream_prefix %>"
|
142
|
-
}
|
143
|
-
},
|
144
|
-
<% end %>
|
145
|
-
"essential": true
|
146
|
-
}
|
147
|
-
]
|
148
|
-
}
|
149
|
-
```
|
150
|
-
|
151
|
-
The instance variable values are specified in `ufo/task_definitions.rb` via a DSL. Here's the
|
152
|
-
|
153
|
-
|
154
|
-
```ruby
|
155
|
-
task_definition "hi-web-prod" do
|
156
|
-
source "main" # will use ufo/templates/main.json.erb
|
157
|
-
variables(
|
158
|
-
family: task_definition_name,
|
159
|
-
# image: tongueroo/hi:ufo-[timestamp]=[sha]
|
160
|
-
image: helper.full_image_name,
|
161
|
-
environment: helper.env_file('.env.prod')
|
162
|
-
name: "web",
|
163
|
-
container_port: helper.dockerfile_port,
|
164
|
-
command: ["bin/web"]
|
165
|
-
)
|
166
|
-
end
|
167
|
-
```
|
168
|
-
|
169
|
-
The task\_definitions.rb file has some special variables and helper methods available. These helper methods provide useful contextual information about the project. For example, one of the variable provides the exposed port in the Dockerfile of the project. This why if someone changes the exported port in the Dockerfile, he will not "forgot" to also update the ufo variable as it is automatically referenced. Here is a list of the important helpers:
|
19
|
+
If you want to quickly install ufo without having to worry about ufo’s dependencies you can simply install the Bolts Toolbelt which has ufo included.
|
170
20
|
|
171
|
-
|
172
|
-
|
173
|
-
* **helper.env_vars(text)** — This method takes a block of text that contains the env values in key=value format and converts that block of text to the proper task definition json format.
|
174
|
-
* **helper.env_file(path)** — This method takes an `.env` file which contains a simple key value list of environment variables and converts the list to the proper task definition json format.
|
175
|
-
|
176
|
-
The 2 classes which provide these special helper methods are in [ufo/dsl.rb](https://github.com/tongueroo/ufo/blob/master/lib/ufo/dsl.rb) and [ufo/dsl/helper.rb](https://github.com/tongueroo/ufo/blob/master/lib/ufo/dsl/helper.rb). Refer to these classes for the full list of the special variables and methods.
|
177
|
-
|
178
|
-
### Shipping Multiple Services with bin/deploy
|
179
|
-
|
180
|
-
A common pattern is to have 3 processes: web, worker, and clock. This is very common in rails applcations. The web process handles web traffic, the worker process handles background job processing that would be too slow and potentially block web requests, and a clock process is typically used to schedule recurring jobs. These processes use the same codebase, or same docker image, but have slightly different run time settings. For example, the docker run command for a web process could be [puma](http://puma.io/) and the command for a worker process could be [sidekiq](http://sidekiq.org/). Environment variables are sometimes different also. The important key is that the same docker image is used for all 3 services but the task definition for each service is different.
|
181
|
-
|
182
|
-
This is easily accomplished with the `bin/deploy` wrapper script that the `ufo init` command initially generates. The starter script example shows you how you can use ufo to generate one docker image and use the same image to deploy to all 3 services. Here is an example `bin/deploy` script:
|
183
|
-
|
184
|
-
```bash
|
185
|
-
#!/bin/bash -xe
|
186
|
-
|
187
|
-
ufo ship hi-worker-prod --cluster prod --no-wait
|
188
|
-
ufo ship hi-clock-prod --cluster prod --no-wait --no-docker
|
189
|
-
ufo ship hi-web-prod --cluster prod --no-docker
|
21
|
+
```sh
|
22
|
+
brew cask install boltopslabs/software/bolts
|
190
23
|
```
|
191
24
|
|
192
|
-
|
25
|
+
Or if you prefer you can install ufo with RubyGems
|
193
26
|
|
194
|
-
|
195
|
-
|
196
|
-
Ufo assumes a convention that service\_name and the task\_name are the same. If you would like to override this convention then you can specify the task name.
|
197
|
-
|
198
|
-
```
|
199
|
-
ufo ship hi-web-prod --task my-task
|
27
|
+
```sh
|
28
|
+
gem install ufo
|
200
29
|
```
|
201
30
|
|
202
|
-
|
203
|
-
|
204
|
-
```ruby
|
205
|
-
task_definition "my-task" do
|
206
|
-
source "web" # this corresponds to the file in "ufo/templates/web.json.erb"
|
207
|
-
variables(
|
208
|
-
family: "my-task",
|
209
|
-
....
|
210
|
-
)
|
211
|
-
end
|
212
|
-
|
213
|
-
```
|
31
|
+
Full installation instructions are at [Install Ufo](http://ufoships.com/docs/install/).
|
214
32
|
|
215
|
-
|
33
|
+
## Quick Start
|
216
34
|
|
217
|
-
|
35
|
+
To quickly demonstrate how simple it is to use ufo we will use an example app from [tongueroo/hi](https://github.com/tongueroo/ufo). The app is a barebones sinatra app. Here are the steps:
|
218
36
|
|
219
|
-
|
220
|
-
|
221
|
-
|
222
|
-
|
223
|
-
ufo
|
224
|
-
|
225
|
-
|
226
|
-
Build the task definitions.
|
227
|
-
|
228
|
-
```bash
|
229
|
-
ufo tasks build
|
230
|
-
ufo tasks register # will register all genreated task definitinos in the ufo/output folder
|
37
|
+
```sh
|
38
|
+
brew cask install boltopslabs/software/bolts
|
39
|
+
git clone https:///github.com/tongueroo/hi.git
|
40
|
+
cd hi
|
41
|
+
ufo init --app=hi --env stag --cluster=stag --image=tongueroo/hi
|
42
|
+
ufo ship hi-web-stag
|
231
43
|
```
|
232
44
|
|
233
|
-
|
234
|
-
|
235
|
-
```bash
|
236
|
-
ufo ship hi-web-prod --no-docker
|
237
|
-
```
|
238
|
-
Note if you use the `--no-docker` option you should ensure that you have already push a docker image to your docker register. Or else the task will not be able to spin up because the docker image does not exist. I recommend that you normally use `ufo ship` most of the time.
|
239
|
-
|
240
|
-
|
241
|
-
### Automated Docker Images Clean Up
|
242
|
-
|
243
|
-
Ufo can be configured to automatically clean old images from the ECR registry after the deploy completes. I normally set `~/.ufo/settings.yml` like so:
|
244
|
-
|
245
|
-
```yaml
|
246
|
-
ecr_keep: 30
|
247
|
-
```
|
45
|
+
Congratulations, you have successfully used ufo to deploy to an ECS service.
|
248
46
|
|
249
|
-
Automated Docker images clean up only works if you are using ECR registry.
|
250
47
|
|
251
|
-
##
|
48
|
+
## Articles
|
252
49
|
|
253
|
-
|
254
|
-
|
255
|
-
```
|
256
|
-
ufo task hi-migrate-prod
|
257
|
-
```
|
258
|
-
|
259
|
-
You will need to define a task definition for the migrate command also in `ufo/task_definitions.rb`. If you only need to override the Docker command and can re-use an existing task definition like `hi-web-prod`. You can use the `--command` option:
|
260
|
-
|
261
|
-
```
|
262
|
-
ufo task hi-web-prod --command bin/migrate
|
263
|
-
ufo task hi-web-prod --command bin/with_env bundle exec rake db:migrate:redo VERSION=xxx
|
264
|
-
```
|
265
|
-
|
266
|
-
The `--command` option takes a string. If the string has brackets in it then it will be evaluated as an Array but the option must be a string.
|
267
|
-
|
268
|
-
## Scale
|
269
|
-
|
270
|
-
There is a convenience wrapper that simple executes `aws ecs update-service --service [SERVICE] --desired-count [COUNT]`
|
271
|
-
|
272
|
-
```
|
273
|
-
ufo scale hi-web 1
|
274
|
-
```
|
275
|
-
|
276
|
-
## Destroy
|
277
|
-
|
278
|
-
To scale down the service and destroy it:
|
279
|
-
|
280
|
-
```
|
281
|
-
ufo destroy hi-web
|
282
|
-
```
|
50
|
+
* This blog post provides an introduction to the tool: [Ufo - Build Docker Containers and Ship Them to AWS ECS](https://medium.com/@tongueroo/ufo-easily-build-docker-containers-and-ship-them-to-aws-ecs-15556a2b39f#.qqu8o4wal).
|
51
|
+
* This presentation covers ufo also: [Ufo Ship on AWS ECS](http://www.slideshare.net/tongueroo/ufo-ship-for-aws-ecs-70885296)
|
283
52
|
|
284
|
-
### More Help
|
285
53
|
|
286
|
-
```
|
287
|
-
ufo help
|
288
|
-
```
|
289
54
|
## Contributing
|
290
55
|
|
291
56
|
Bug reports and pull requests are welcome on GitHub at [https://github.com/tongueroo/ufo/issues](https://github.com/tongueroo/ufo/issues).
|
@@ -0,0 +1,15 @@
|
|
1
|
+
---
|
2
|
+
title: Automated Clean Up
|
3
|
+
---
|
4
|
+
|
5
|
+
Ufo can be configured to automatically clean old images from the ECR registry after the deploy completes by configuring the your [settings.yml] file like so:
|
6
|
+
|
7
|
+
```yaml
|
8
|
+
ecr_keep: 30
|
9
|
+
```
|
10
|
+
|
11
|
+
Automated Docker images clean up only works if you are using ECR registry.
|
12
|
+
|
13
|
+
<a id="prev" class="btn btn-basic" href="{% link _docs/migrations.md %}">Back</a>
|
14
|
+
<a id="next" class="btn btn-primary" href="{% link _docs/next-steps.md %}">Next Step</a>
|
15
|
+
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
data/docs/_docs/conventions.md
CHANGED
@@ -6,7 +6,7 @@ Ufo uses a set of naming conventions. This helps enforce some best practices an
|
|
6
6
|
|
7
7
|
### Service and Task Names Convention
|
8
8
|
|
9
|
-
|
9
|
+
Ufo assumes a convention that service\_name and the task\_name are the same. If you would like to override this convention then you can specify the task name.
|
10
10
|
|
11
11
|
```
|
12
12
|
ufo ship hi-web-prod --task my-task
|
@@ -39,7 +39,6 @@ You can also bypass the prompt by specifying the target group arn as part of the
|
|
39
39
|
ufo ship hi-web-prod --target-group=arn:aws:elasticloadbalancing:us-east-1:12345689:targetgroup/hi-web-prod/12345
|
40
40
|
```
|
41
41
|
|
42
|
-
<a id="prev" class="btn btn-basic" href="{% link _docs/
|
43
|
-
<a id="next" class="btn btn-primary" href="{% link _docs/
|
42
|
+
<a id="prev" class="btn btn-basic" href="{% link _docs/helpers.md %}">Back</a>
|
43
|
+
<a id="next" class="btn btn-primary" href="{% link _docs/run-in-pieces.md %}">Next Step</a>
|
44
44
|
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
45
|
-
|
@@ -0,0 +1,22 @@
|
|
1
|
+
---
|
2
|
+
title: Helpers
|
3
|
+
---
|
4
|
+
|
5
|
+
The task\_definitions.rb file has access to special variables and helper methods available. These helper methods provide useful contextual information about the project.
|
6
|
+
|
7
|
+
For example, one of the variable provides the exposed port in the Dockerfile of the project. This is useful if someone changes the exported port in the Dockerfile, he likely to forget to also update the ufo variable so it is referenced via the helper. Here is a list of the important helpers:
|
8
|
+
|
9
|
+
Helper | Description
|
10
|
+
------------- | -------------
|
11
|
+
full\_image\_name | The full docker image name that ufo builds. The "base" portion of the docker image name is defined in ufo/settings.yml. For example, the base portion is `tongueroo/hi` and the full image name is `tongueroo/hi:ufo-[timestamp]-[sha]`. The base name does not include the generated Docker tag, which contains a timestamp and git sha of the Dockerfile that is used.
|
12
|
+
dockerfile\_port | Exposed port extracted from the Dockerfile of the project.
|
13
|
+
env_vars(text) | This method takes a block of text that contains the env values in key=value format and converts that block of text to the proper task definition json format.
|
14
|
+
env_file(path) | This method takes an `.env` file which contains a simple key value list of environment variables and converts the list to the proper task definition json format.
|
15
|
+
|
16
|
+
To call the helper in task_definitions.rb you must add `helper.` in front. So full\_image\_name is called via `helper.full_image_name`.
|
17
|
+
|
18
|
+
The 2 classes which provide these special helper methods are in [ufo/dsl.rb](https://github.com/tongueroo/ufo/blob/master/lib/ufo/dsl.rb) and [ufo/dsl/helper.rb](https://github.com/tongueroo/ufo/blob/master/lib/ufo/dsl/helper.rb). Refer to these classes for the full list of the special variables and methods.
|
19
|
+
|
20
|
+
<a id="prev" class="btn btn-basic" href="{% link _docs/settings.md %}">Back</a>
|
21
|
+
<a id="next" class="btn btn-primary" href="{% link _docs/conventions.md %}">Next Step</a>
|
22
|
+
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
data/docs/_docs/install.md
CHANGED
@@ -4,7 +4,7 @@ title: Installation
|
|
4
4
|
|
5
5
|
### Install with Bolts Toolbelt
|
6
6
|
|
7
|
-
If you want to quickly install ufo without having to worry about ufo's
|
7
|
+
If you want to quickly install ufo without having to worry about ufo's dependencies you can simply install the Bolts Toolbelt which has ufo included.
|
8
8
|
|
9
9
|
```sh
|
10
10
|
brew cask install boltopslabs/software/bolts
|
@@ -26,6 +26,11 @@ Or you can add ufo to your Gemfile in your project if you are working with a rub
|
|
26
26
|
gem "ufo"
|
27
27
|
{% endhighlight %}
|
28
28
|
|
29
|
+
### Dependencies
|
30
|
+
|
31
|
+
* Docker: You will need a working version of [Docker](https://docs.docker.com/engine/installation/) installed as ufo shells out and calls the `docker` command.
|
32
|
+
* AWS: Set up your AWS credentials at `~/.aws/credentials` and `~/.aws/config`. This is the [AWS standard way of setting up credentials](https://aws.amazon.com/blogs/security/a-new-and-standardized-way-to-manage-credentials-in-the-aws-sdks/).
|
33
|
+
|
29
34
|
<a id="prev" class="btn btn-basic" href="/docs/">Back</a>
|
30
35
|
<a id="next" class="btn btn-primary" href="{% link _docs/structure.md %}">Next Step</a>
|
31
36
|
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
@@ -0,0 +1,32 @@
|
|
1
|
+
---
|
2
|
+
title: Database Migrations
|
3
|
+
---
|
4
|
+
|
5
|
+
A common task is to run database migrations with newer code before deploying the actual code. This is easily achieved with the `ufo task` command. Here's an example:
|
6
|
+
|
7
|
+
```sh
|
8
|
+
ufo task hi-web-prod --command bundle exec rake db:migrate
|
9
|
+
```
|
10
|
+
|
11
|
+
It nice to wrap the commands in a wrapper script in case you have to do things like the load the environment.
|
12
|
+
|
13
|
+
```sh
|
14
|
+
ufo task hi-web-prod --command bin/migrate
|
15
|
+
```
|
16
|
+
|
17
|
+
The `bin/migrate` script can look like this:
|
18
|
+
|
19
|
+
```bash
|
20
|
+
#!/bin/bash
|
21
|
+
bundle exec rake db:migrate
|
22
|
+
```
|
23
|
+
|
24
|
+
The `ufo task` command is generalized so you can actually run any one-off task. It is not just limited to running migrations. The `ufo task` command performs the following:
|
25
|
+
|
26
|
+
1. Builds the docker image and pushes it to a registry
|
27
|
+
2. Registers the ECS Task definition
|
28
|
+
3. Runs an one-off ECS Task
|
29
|
+
|
30
|
+
<a id="prev" class="btn btn-basic" href="{% link _docs/single-task.md %}">Back</a>
|
31
|
+
<a id="next" class="btn btn-primary" href="{% link _docs/automated-cleanup.md %}">Next Step</a>
|
32
|
+
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
data/docs/_docs/next-steps.md
CHANGED
@@ -12,7 +12,7 @@ From here, there are a few resources that can help you continue along:
|
|
12
12
|
|
13
13
|
Everyone can contribute to make ufo better, including the documentation. These docs are of the same ufo repo in the [docs folder](https://github.com/tongueroo/ufo/tree/master/docs). Please fork the project and open a pull request! We love your pull requests. Contributions are encouraged and welcomed!
|
14
14
|
|
15
|
-
<a id="prev" class="btn btn-basic" href="{% link _docs/
|
15
|
+
<a id="prev" class="btn btn-basic" href="{% link _docs/automated-cleanup.md %}">Back</a>
|
16
16
|
<a id="next" class="btn btn-primary" href="{% link articles.md %}">Next Step</a>
|
17
17
|
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
18
18
|
|
@@ -0,0 +1,30 @@
|
|
1
|
+
---
|
2
|
+
title: Run in Pieces
|
3
|
+
---
|
4
|
+
|
5
|
+
The `ufo ship` command goes through a few stages: building the docker image, registering the task defiintions and updating the ECS service. The CLI exposes each of the steps as separate commands. Here is now you would be able to run each of the steps in pieces.
|
6
|
+
|
7
|
+
Build the docker image first.
|
8
|
+
|
9
|
+
```bash
|
10
|
+
ufo docker build
|
11
|
+
ufo docker build --push # will also push to the docker registry
|
12
|
+
```
|
13
|
+
|
14
|
+
Build the task definitions.
|
15
|
+
|
16
|
+
```bash
|
17
|
+
ufo tasks build
|
18
|
+
ufo tasks register # will register all genreated task definitinos in the ufo/output folder
|
19
|
+
```
|
20
|
+
|
21
|
+
Skips all the build docker phases of a deploy sequence and only update the service with the task definitions.
|
22
|
+
|
23
|
+
```bash
|
24
|
+
ufo ship hi-web-prod --no-docker
|
25
|
+
```
|
26
|
+
Note if you use the `--no-docker` option you should ensure that you have already push a docker image to your docker registry. Or else the task will not be able to spin up because the docker image does not exist. It is normally recommended that you normally use `ufo ship`.
|
27
|
+
|
28
|
+
<a id="prev" class="btn btn-basic" href="{% link _docs/conventions.md %}">Back</a>
|
29
|
+
<a id="next" class="btn btn-primary" href="{% link _docs/single-task.md %}">Next Step</a>
|
30
|
+
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
@@ -52,6 +52,6 @@ docker_keep: 30
|
|
52
52
|
```
|
53
53
|
|
54
54
|
<a id="prev" class="btn btn-basic" href="{% link _docs/ufo-help.md %}">Back</a>
|
55
|
-
<a id="next" class="btn btn-primary" href="{% link _docs/
|
55
|
+
<a id="next" class="btn btn-primary" href="{% link _docs/helpers.md %}">Next Step</a>
|
56
56
|
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
57
57
|
|
@@ -0,0 +1,29 @@
|
|
1
|
+
---
|
2
|
+
title: Run Single Task
|
3
|
+
---
|
4
|
+
|
5
|
+
Sometimes you do not want to run a long running `service` but a one time task. Running Rails migrations are a good example of a one off task. Here is an example of how you would run a one time task.
|
6
|
+
|
7
|
+
```
|
8
|
+
ufo task hi-web-prod --command bundle exec rake db:migrate
|
9
|
+
```
|
10
|
+
|
11
|
+
At the end of the output you should see you the task ARN:
|
12
|
+
|
13
|
+
```sh
|
14
|
+
$ ufo task hi-web-prod --command bundle exec rake db:migrate
|
15
|
+
...
|
16
|
+
Running task_definition: hi-web-prod
|
17
|
+
Task ARN: arn:aws:ecs:us-west-2:994926937775:task/a0e4229d-3d39-4b26-9151-6ab6869b84d4
|
18
|
+
$
|
19
|
+
```
|
20
|
+
|
21
|
+
You can describe that task for more details:
|
22
|
+
|
23
|
+
```sh
|
24
|
+
aws ecs describe-tasks --tasks arn:aws:ecs:us-west-2:994926937775:task/a0e4229d-3d39-4b26-9151-6ab6869b84d4
|
25
|
+
```
|
26
|
+
|
27
|
+
<a id="prev" class="btn btn-basic" href="{% link _docs/run-in-pieces.md %}">Back</a>
|
28
|
+
<a id="next" class="btn btn-primary" href="{% link _docs/migrations.md %}">Next Step</a>
|
29
|
+
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
@@ -1,8 +1,8 @@
|
|
1
1
|
---
|
2
|
-
title:
|
2
|
+
title: Build Docker
|
3
3
|
---
|
4
4
|
|
5
|
-
###
|
5
|
+
### Build the Docker Image
|
6
6
|
|
7
7
|
Let's use the `ufo docker build` command to build the docker image. The command uses the `Dockerfile` in the current project to build the docker image. You use your own Dockerfile so you have fully control over how you would like the image to be built. For this tutorial we will continue to use the [tongueroo/hi](https://github.com/tongueroo/hi) app and it's Dockerfile. Let's run the command:
|
8
8
|
|
@@ -1,5 +1,5 @@
|
|
1
1
|
---
|
2
|
-
title:
|
2
|
+
title: Setup Ufo
|
3
3
|
---
|
4
4
|
|
5
5
|
The easiest way to create this ufo folder is by using the `ufo init` command. For this tutorial we'll [tongueroo/hi](https://github.com/tongueroo/hi) which is a small test sinatra app.
|
@@ -15,7 +15,7 @@ You should see output similiar to this:
|
|
15
15
|
|
16
16
|
<img src="/img/tutorials/ufo-init.png" class="doc-photo" />
|
17
17
|
|
18
|
-
The standard directory structure of the ufo folder looks like this:
|
18
|
+
The `ufo init` command generated a few starter ufo files for you. The standard directory structure of the ufo folder looks like this:
|
19
19
|
|
20
20
|
```sh
|
21
21
|
ufo
|
@@ -28,6 +28,31 @@ ufo
|
|
28
28
|
|
29
29
|
The explanation of the folders and files were covered in detailed earlier at [Structure]({% link _docs/structure.md %}).
|
30
30
|
|
31
|
+
### Settings
|
32
|
+
|
33
|
+
Take a look at the `ufo/settings.yml` file and notice that it contains some default configuration settings so you do not have to type out these options repeatedly for some of the ufo commands.
|
34
|
+
|
35
|
+
```yaml
|
36
|
+
image: tongueroo/hi
|
37
|
+
service_cluster:
|
38
|
+
default: stag # default cluster
|
39
|
+
# can override the default cluster for each service. CLI overrides all of these settings.
|
40
|
+
hi-web-stag:
|
41
|
+
hi-clock-stag:
|
42
|
+
hi-worker-stag:
|
43
|
+
```
|
44
|
+
|
45
|
+
The `image` value is the name that ufo will use as a base to generate a Docker image name.
|
46
|
+
|
47
|
+
The `service_cluster` mapping provides a way to set default service-to-cluster mappings so that you do not have to specify the `--cluster` repeatedly. This is very helpful. For example:
|
48
|
+
|
49
|
+
```
|
50
|
+
ufo ship hi-web-stag --cluster hi-cluster
|
51
|
+
ufo ship hi-web-stag # same as above because it is configured in ufo/settings.yml
|
52
|
+
ufo ship hi-web-stag --cluster special-cluster # overrides the default setting in `ufo/settings.yml`.
|
53
|
+
```
|
54
|
+
|
55
|
+
|
31
56
|
<a id="prev" class="btn btn-basic" href="{% link _docs/tutorial.md %}">Back</a>
|
32
57
|
<a id="next" class="btn btn-primary" href="{% link _docs/tutorial-ufo-docker-build.md %}">Next Step</a>
|
33
58
|
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
@@ -1,11 +1,38 @@
|
|
1
1
|
---
|
2
|
-
title:
|
2
|
+
title: Deploy One App
|
3
3
|
---
|
4
4
|
|
5
5
|
### Step 3 - Ship the Code to ECS
|
6
6
|
|
7
7
|
In this guide we have walked through what ufo does step by step. First ufo builds the Docker image with `ufo docker build`. Then it will build and register the ECS task definitions with the `ufo tasks` commands. Now we'll deploy the code to ECS.
|
8
8
|
|
9
|
+
```sh
|
10
|
+
ufo ship hi-web-stag --cluster stag
|
11
|
+
```
|
12
|
+
|
13
|
+
Note, when we ran `ufo init` earlier, it configured `ufo/settings.yml` to map hi-web-stag to the `stag` cluster with the service_cluster option. This nicely simplifies the command to
|
14
|
+
|
15
|
+
```bash
|
16
|
+
ufo ship hi-web-stag
|
17
|
+
```
|
18
|
+
|
19
|
+
When you run `ufo ship hi-web-stag`:
|
20
|
+
|
21
|
+
1. It builds the docker image.
|
22
|
+
2. Generates a task definition and registers it.
|
23
|
+
3. Updates the ECS service to use it.
|
24
|
+
|
25
|
+
If the ECS service hi-web-stag does not yet exist, ufo will create the service for you. Ufo will also automatically create the ECS cluster. If you are relying on this tool to create the cluster, you still need to associate ECS Container Instances to the cluster yourself.
|
26
|
+
|
27
|
+
By convention, if the service has a container name web, you'll get prompted to create an ELB and specify a target group arn. The ELB and target group must already exist. You can bypass the prompt and specify the target group ARN as part of the ship command or with the `--no-target-group-prompt` option. The elb target group only gets associated with the ECS service if the service is being created for the first time. If the service already exists then the `--target-group` parameter just gets ignored and the ECS task simply gets updated. Example:
|
28
|
+
|
29
|
+
|
30
|
+
```bash
|
31
|
+
ufo ship hi-web-stag --target-group=arn:aws:elasticloadbalancing:us-east-1:12345689:targetgroup/hi-web-stag/12345
|
32
|
+
```
|
33
|
+
|
34
|
+
Let's go back to the original command and take a look at the output:
|
35
|
+
|
9
36
|
```sh
|
10
37
|
ufo ship hi-web-stag
|
11
38
|
```
|
@@ -36,6 +63,8 @@ Checking the ECS console you should see something like this:
|
|
36
63
|
|
37
64
|
<img src="/img/tutorials/ecs-console-ufo-ship.png" class="doc-photo" />
|
38
65
|
|
66
|
+
You have successfully shipped a docker image to ECS! 🍾🥂
|
67
|
+
|
39
68
|
### Skipping Previous Steps
|
40
69
|
|
41
70
|
The `ufo ship` command will automatically calls the steps we called manually in the previous pages: `ufo build` and `ufo tasks`.
|
@@ -1,8 +1,12 @@
|
|
1
1
|
---
|
2
|
-
title:
|
2
|
+
title: Deploy Multiple Apps
|
3
3
|
---
|
4
4
|
|
5
|
-
You might have noticed in in the tutorial that the starter ufo folder
|
5
|
+
You might have noticed in in the tutorial that the generated starter ufo folder contains 3 task definitions a web, worker and clock role. This is a common pattern. The web process handles web traffic, the worker process handles background job processing that would be too slow and potentially block web requests, and a clock process is typically used to schedule recurring jobs.
|
6
|
+
|
7
|
+
These processes use the same codebase and same docker image, but have slightly different run time settings. The docker run command for a web process could be [puma](http://puma.io/) and the command for a worker process could be [sidekiq](http://sidekiq.org/). Environment variables are also sometimes different. The important key is that the same docker image is used for all 3 services but the task definition for each service is slightly different.
|
8
|
+
|
9
|
+
While we can use the `ufo ship` command to deploy to all 3 service roles individually like so:
|
6
10
|
|
7
11
|
```sh
|
8
12
|
ufo ship hi-web-stag
|
@@ -10,7 +14,7 @@ ufo ship hi-worker-stag
|
|
10
14
|
ufo ship hi-clock-stag
|
11
15
|
```
|
12
16
|
|
13
|
-
This
|
17
|
+
This would build a new Docker image for each process. We actually want have the same docker image running on all of these roles. In this case where we want to use the *same* Docker image for all 3 roles, ufo provides a `ufo ships` command.
|
14
18
|
|
15
19
|
### ufo ships
|
16
20
|
|
@@ -22,7 +26,12 @@ You can check on the ECS console and should see something similar to this:
|
|
22
26
|
|
23
27
|
<img src="/img/tutorials/ecs-console-ufo-ships.png" class="doc-photo" />
|
24
28
|
|
29
|
+
You can shorten the command by taking advantage of shell expansion:
|
30
|
+
|
31
|
+
```sh
|
32
|
+
ufo ships hi-{web,worker,clock}-stag
|
33
|
+
```
|
34
|
+
|
25
35
|
<a id="prev" class="btn btn-basic" href="{% link _docs/tutorial-ufo-ship.md %}">Back</a>
|
26
36
|
<a id="next" class="btn btn-primary" href="{% link _docs/commands.md %}">Next Step</a>
|
27
37
|
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
28
|
-
|
@@ -1,16 +1,18 @@
|
|
1
1
|
---
|
2
|
-
title:
|
2
|
+
title: Task Definitions
|
3
3
|
---
|
4
4
|
|
5
|
-
###
|
5
|
+
### Build the ECS Task Definitions
|
6
6
|
|
7
|
-
Now that we have a docker image pushed to a registry we can use that image for ECS. Ufo takes that image and adds it to an ECS task definition. This is where ufo
|
7
|
+
Now that we have a docker image pushed to a registry we can use that image for ECS. Ufo takes that image and adds it to an ECS task definition. This is where ufo is super powerful. Ufo gives you the power to build and control your ECS task definition easily.
|
8
8
|
|
9
9
|
Let's take a look at the 2 files that are used by ufo to build the the ECS task definition. These files were generated by the `ufo init` command at the beginning.
|
10
10
|
|
11
11
|
1. ufo/templates/main.json.erb
|
12
12
|
2. ufo/task_definitions.rb
|
13
13
|
|
14
|
+
Ufo task definitions are written as an ERB template that makes it every easily accessible and configurable to your requirements. Here is is an example of an ERB template `ufo/templates/main.json.erb` that shows how easy it is to modfied the task definition you want to be uploaded by ufo:
|
15
|
+
|
14
16
|
**main.json.erb**:
|
15
17
|
|
16
18
|
```json
|
@@ -55,6 +57,8 @@ Let's take a look at the 2 files that are used by ufo to build the the ECS task
|
|
55
57
|
}
|
56
58
|
```
|
57
59
|
|
60
|
+
The instance variable values are specified in `ufo/task_definitions.rb` via a DSL. Here's the file:
|
61
|
+
|
58
62
|
**task_definitions.rb**:
|
59
63
|
|
60
64
|
```
|
@@ -100,7 +104,11 @@ task_definition "hi-clock-stag" do
|
|
100
104
|
end
|
101
105
|
```
|
102
106
|
|
103
|
-
Ufo uses the ERB template in `main.json.erb` and combines it with the variables defined in the task definition declarations in `task_definitions.rb` and generates the raw AWS formatted task definition in the `output` folder. In this case there are 3 task_definitions so there will be 3 generated output files.
|
107
|
+
Ufo uses the ERB template in `main.json.erb` and combines it with the variables defined in the task definition declarations in `task_definitions.rb` and generates the raw AWS formatted task definition in the `output` folder. In this case there are 3 task_definitions so there will be 3 generated output files.
|
108
|
+
|
109
|
+
If you need to modify the task definition template to suite your own needs it is super simple, just edit `main.json.erb`. You do not have to dive deep into internal code somewhere. It is all there for you to fully control.
|
110
|
+
|
111
|
+
The task_definition.rb has access to some useful helper methods detailed in [Helpers]({% link _docs/helpers.md %}).
|
104
112
|
|
105
113
|
Let's build the task definitions:
|
106
114
|
|
@@ -144,12 +152,12 @@ Let's take a look at one of the generated files: `ufo/output/hi-web-stag.json`.
|
|
144
152
|
}
|
145
153
|
```
|
146
154
|
|
147
|
-
###
|
155
|
+
### Register the ECS Task Definitions
|
148
156
|
|
149
157
|
You have built the ecs task definitions locally on your machine. To register the task definitions in output run this command:
|
150
158
|
|
151
159
|
```sh
|
152
|
-
ufo
|
160
|
+
ufo tasks register
|
153
161
|
```
|
154
162
|
|
155
163
|
You should see something similiar to this:
|
data/docs/_docs/ufo-destroy.md
CHANGED
@@ -17,4 +17,3 @@ ufo destroy hi-web-stag --sure
|
|
17
17
|
<a id="prev" class="btn btn-basic" href="{% link _docs/ufo-scale.md %}">Back</a>
|
18
18
|
<a id="next" class="btn btn-primary" href="{% link _docs/ufo-docker-build.md %}">Next Step</a>
|
19
19
|
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
20
|
-
|
data/docs/_docs/ufo-help.md
CHANGED
@@ -17,6 +17,6 @@ ufo ships -h
|
|
17
17
|
```
|
18
18
|
|
19
19
|
<a id="prev" class="btn btn-basic" href="{% link _docs/ufo-tasks-register.md %}">Back</a>
|
20
|
-
<a id="next" class="btn btn-primary" href="{% link _docs/
|
20
|
+
<a id="next" class="btn btn-primary" href="{% link _docs/settings.md %}">Next Step</a>
|
21
21
|
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
22
22
|
|
data/docs/_docs/ufo-scale.md
CHANGED
@@ -20,3 +20,4 @@ While scaling via this method is quick and convenient the [ECS Service AutoScali
|
|
20
20
|
<a id="next" class="btn btn-primary" href="{% link _docs/ufo-destroy.md %}">Next Step</a>
|
21
21
|
<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
|
22
22
|
|
23
|
+
|
data/docs/_includes/contact.html
CHANGED
@@ -10,7 +10,7 @@
|
|
10
10
|
<div class="row">
|
11
11
|
<div class="col-lg-12 text-center">
|
12
12
|
<div id="success"></div>
|
13
|
-
<a href="{% link quick-start.md %}" class="btn btn-primary btn-xl">Quick Start</a>
|
13
|
+
<a id="next" href="{% link quick-start.md %}" class="btn btn-primary btn-xl">Quick Start</a>
|
14
14
|
</div>
|
15
15
|
</div>
|
16
16
|
</div>
|
data/docs/_includes/footer.html
CHANGED
@@ -6,8 +6,9 @@
|
|
6
6
|
<div class="footer-col col-md-4">
|
7
7
|
<h3>More Tools</h3>
|
8
8
|
<ul class="list-unstyled tools">
|
9
|
+
<li><a href="http://sonic-screwdriver.cloud">Sonic Screwdriver</a></li>
|
9
10
|
<li><a href="http://lono.cloud">Lono</a></li>
|
10
|
-
<li><a href="http://
|
11
|
+
<li><a href="http://jack-eb.com">Jack</a></li>
|
11
12
|
<li><a href="https://boltops.com/toolbelt">Toolbelt</a></li>
|
12
13
|
</ul>
|
13
14
|
</div>
|
data/docs/_includes/subnav.html
CHANGED
@@ -13,7 +13,7 @@
|
|
13
13
|
<li><a href="{% link _docs/tutorial-ufo-docker-build.md %}">Build Docker</a></li>
|
14
14
|
<li><a href="{% link _docs/tutorial-ufo-tasks-build.md %}">Task Definitions</a></li>
|
15
15
|
<li><a href="{% link _docs/tutorial-ufo-ship.md %}">Deploy One App</a></li>
|
16
|
-
<li><a href="{% link _docs/tutorial-ufo-ships.md %}">Deploy Apps</a></li>
|
16
|
+
<li><a href="{% link _docs/tutorial-ufo-ships.md %}">Deploy Multiple Apps</a></li>
|
17
17
|
</ul>
|
18
18
|
</li>
|
19
19
|
<li><a href="{% link _docs/commands.md %}">Commands</a>
|
@@ -32,8 +32,13 @@
|
|
32
32
|
<li><a href="{% link _docs/ufo-help.md %}">ufo help</a></li>
|
33
33
|
</ul>
|
34
34
|
</li>
|
35
|
-
<li><a href="{% link _docs/
|
35
|
+
<li><a href="{% link _docs/settings.md %}">Settings</a></li>
|
36
|
+
<li><a href="{% link _docs/helpers.md %}">Helpers</a></li>
|
36
37
|
<li><a href="{% link _docs/conventions.md %}">Conventions</a></li>
|
38
|
+
<li><a href="{% link _docs/run-in-pieces.md %}">Run In Pieces</a></li>
|
39
|
+
<li><a href="{% link _docs/single-task.md %}">Run Single Task</a></li>
|
40
|
+
<li><a href="{% link _docs/migrations.md %}">Database Migrations</a></li>
|
41
|
+
<li><a href="{% link _docs/automated-cleanup.md %}">Automated Cleanup</a></li>
|
37
42
|
<li><a href="{% link _docs/next-steps.md %}">Next Steps</a></li>
|
38
43
|
<li><a href="{% link articles.md %}">Articles</a></li>
|
39
44
|
</ul>
|
@@ -10,4 +10,4 @@ Option | Description
|
|
10
10
|
`--pretty` | This boolean option determines ufo generates the task definitions in output in a pretty human readable format.
|
11
11
|
`--stop-old-tasks` | This boolean option determines if ufo will call ecs stop-task on the old tasks after deployment. Sometimes old tasks hang around for a little bit with ECS this forces them along a little quicker.
|
12
12
|
`--ecr-keep` | This integer option determines how many old docker images to keep around. Ufo will automatically delete and clean up docker images at the end of this process. The default is reasonable large at 30.
|
13
|
-
`--cluster` | This decides what cluster to use. This can also be set in ufo/settings.yml covered in [Settings]({% link _docs/
|
13
|
+
`--cluster` | This decides what cluster to use. This can also be set in ufo/settings.yml covered in [Settings]({% link _docs/settings.md %}). The cli option takes highest precedence.
|
data/docs/quick-start.md
CHANGED
@@ -3,10 +3,5 @@
|
|
3
3
|
# Generated started bin/deploy script. Meant to be example only and should probably
|
4
4
|
# be overridden.
|
5
5
|
|
6
|
-
# Only build docker image
|
7
|
-
ufo
|
8
|
-
# Skipping the docker build phase for the rest of the ship commands
|
9
|
-
ufo ship <%= @app %>-worker --cluster <%= @cluster %> --no-wait --no-docker
|
10
|
-
# The final service will wait for the deploy to finish. Please specify an
|
11
|
-
# Application Load Balancer if creating the service for the first time.
|
12
|
-
ufo ship <%= @app %>-web --cluster <%= @cluster %> --no-docker
|
6
|
+
# Only build one docker image and deploys it to multiple ECS services
|
7
|
+
ufo ships <%= @app %>-{web,clock,worker}-<%= @env %> --cluster <%= @cluster %>
|
@@ -5,6 +5,6 @@ image: <%= @image %>
|
|
5
5
|
service_cluster:
|
6
6
|
default: <%= @cluster %> # default cluster
|
7
7
|
# can override the default cluster for each service. CLI overrides all of these settings.
|
8
|
-
<%= @app %>-web
|
9
|
-
<%= @app %>-clock
|
10
|
-
<%= @app %>-worker
|
8
|
+
<%= @app %>-web-<%= @env %>:
|
9
|
+
<%= @app %>-clock-<%= @env %>:
|
10
|
+
<%= @app %>-worker-<%= @env %>:
|
data/lib/ufo/cli/help.rb
CHANGED
data/lib/ufo/version.rb
CHANGED
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: ufo
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 1.6.
|
4
|
+
version: 1.6.2
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Tung Nguyen
|
8
8
|
autorequire:
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
|
-
date: 2017-06-
|
11
|
+
date: 2017-06-22 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: thor
|
@@ -175,10 +175,16 @@ files:
|
|
175
175
|
- docs/LICENSE
|
176
176
|
- docs/README.md
|
177
177
|
- docs/_config.yml
|
178
|
+
- docs/_docs/automated-cleanup.md
|
178
179
|
- docs/_docs/commands.md
|
179
180
|
- docs/_docs/conventions.md
|
181
|
+
- docs/_docs/helpers.md
|
180
182
|
- docs/_docs/install.md
|
183
|
+
- docs/_docs/migrations.md
|
181
184
|
- docs/_docs/next-steps.md
|
185
|
+
- docs/_docs/run-in-pieces.md
|
186
|
+
- docs/_docs/settings.md
|
187
|
+
- docs/_docs/single-task.md
|
182
188
|
- docs/_docs/structure.md
|
183
189
|
- docs/_docs/tutorial-ufo-docker-build.md
|
184
190
|
- docs/_docs/tutorial-ufo-init.md
|
@@ -194,7 +200,6 @@ files:
|
|
194
200
|
- docs/_docs/ufo-help.md
|
195
201
|
- docs/_docs/ufo-init.md
|
196
202
|
- docs/_docs/ufo-scale.md
|
197
|
-
- docs/_docs/ufo-settings.md
|
198
203
|
- docs/_docs/ufo-ship.md
|
199
204
|
- docs/_docs/ufo-ships.md
|
200
205
|
- docs/_docs/ufo-tasks-build.md
|