ufo 3.1.2 → 3.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/.circleci/bin/commit_docs.sh +26 -0
- data/.circleci/config.yml +13 -0
- data/CHANGELOG.md +6 -0
- data/Gemfile.lock +6 -4
- data/Rakefile +7 -0
- data/docs/_config.yml +3 -0
- data/docs/_docs/conventions.md +3 -3
- data/docs/_docs/install.md +5 -5
- data/docs/_docs/settings.md +3 -3
- data/docs/_docs/structure.md +2 -2
- data/docs/_docs/tutorial-ufo-docker-build.md +1 -1
- data/docs/_docs/tutorial-ufo-init.md +1 -1
- data/docs/_docs/tutorial-ufo-ship.md +3 -7
- data/docs/_docs/tutorial-ufo-ships.md +2 -2
- data/docs/_docs/tutorial-ufo-tasks-build.md +7 -7
- data/docs/_docs/tutorial.md +1 -1
- data/docs/_docs/ufo-env.md +5 -5
- data/docs/_docs/ufo-tasks-register.md +0 -4
- data/docs/_docs/variables.md +6 -7
- data/docs/_includes/content.html +5 -0
- data/docs/_includes/css/main.css +23 -4
- data/docs/_includes/css/ufo.css +9 -9
- data/docs/_includes/reference.md +5 -0
- data/docs/_includes/subnav.html +16 -33
- data/docs/_reference/ufo-completion.md +46 -0
- data/docs/_reference/ufo-completion_script.md +27 -0
- data/docs/_reference/ufo-deploy.md +51 -0
- data/docs/_reference/ufo-destroy.md +34 -0
- data/docs/{_docs → _reference}/ufo-docker-base.md +36 -17
- data/docs/_reference/ufo-docker-build.md +81 -0
- data/docs/_reference/ufo-docker-clean.md +44 -0
- data/docs/_reference/ufo-docker-help.md +15 -0
- data/docs/_reference/ufo-docker-name.md +37 -0
- data/docs/_reference/ufo-docker-push.md +49 -0
- data/docs/_reference/ufo-docker.md +35 -0
- data/docs/_reference/ufo-init.md +74 -0
- data/docs/_reference/ufo-scale.md +30 -0
- data/docs/_reference/ufo-ship.md +100 -0
- data/docs/_reference/ufo-ships.md +77 -0
- data/docs/_reference/ufo-task.md +37 -0
- data/docs/_reference/ufo-tasks-build.md +179 -0
- data/docs/_reference/ufo-tasks-help.md +15 -0
- data/docs/_reference/ufo-tasks-register.md +29 -0
- data/docs/_reference/ufo-tasks.md +35 -0
- data/docs/_reference/ufo-upgrade3.md +23 -0
- data/docs/_reference/ufo-version.md +23 -0
- data/docs/articles.md +2 -0
- data/docs/docs.md +3 -3
- data/docs/quick-start.md +2 -2
- data/docs/reference.md +18 -0
- data/lib/ufo/cli.rb +13 -13
- data/lib/ufo/docker.rb +5 -5
- data/lib/ufo/ecr/auth.rb +6 -1
- data/lib/ufo/ecr/cleaner.rb +1 -1
- data/lib/ufo/help/completion.md +1 -1
- data/lib/ufo/help/completions.md +1 -1
- data/lib/ufo/help/deploy.md +5 -1
- data/lib/ufo/help/destroy.md +7 -3
- data/lib/ufo/help/docker.md +1 -1
- data/lib/ufo/help/docker/base.md +34 -4
- data/lib/ufo/help/docker/build.md +59 -4
- data/lib/ufo/help/docker/clean.md +12 -6
- data/lib/ufo/help/docker/name.md +10 -10
- data/lib/ufo/help/docker/push.md +23 -6
- data/lib/ufo/help/hello.md +1 -1
- data/lib/ufo/help/init.md +43 -5
- data/lib/ufo/help/scale.md +4 -3
- data/lib/ufo/help/ship.md +59 -8
- data/lib/ufo/help/ships.md +35 -9
- data/lib/ufo/help/task.md +1 -1
- data/lib/ufo/help/tasks.md +1 -1
- data/lib/ufo/help/tasks/build.md +155 -4
- data/lib/ufo/help/tasks/register.md +12 -3
- data/lib/ufo/ship.rb +2 -4
- data/lib/ufo/tasks.rb +2 -2
- data/lib/ufo/version.rb +1 -1
- data/spec/lib/ship_spec.rb +2 -1
- data/ufo.gemspec +3 -3
- metadata +44 -21
- data/docs/_docs/commands.md +0 -10
- data/docs/_docs/ufo-deploy.md +0 -30
- data/docs/_docs/ufo-destroy.md +0 -19
- data/docs/_docs/ufo-docker-build.md +0 -79
- data/docs/_docs/ufo-docker-clean.md +0 -27
- data/docs/_docs/ufo-docker-name.md +0 -15
- data/docs/_docs/ufo-docker-push.md +0 -43
- data/docs/_docs/ufo-help.md +0 -22
- data/docs/_docs/ufo-init.md +0 -54
- data/docs/_docs/ufo-scale.md +0 -21
- data/docs/_docs/ufo-ship.md +0 -75
- data/docs/_docs/ufo-ships.md +0 -52
- data/docs/_docs/ufo-tasks-build.md +0 -166
- data/lib/ufo/completion.rb +0 -15
- data/lib/ufo/sub.rb +0 -12
data/lib/ufo/docker.rb
CHANGED
|
@@ -5,7 +5,7 @@ module Ufo
|
|
|
5
5
|
autoload :Dockerfile, 'ufo/docker/dockerfile'
|
|
6
6
|
autoload :Cleaner, 'ufo/docker/cleaner'
|
|
7
7
|
|
|
8
|
-
desc "build", "
|
|
8
|
+
desc "build", "Build docker image."
|
|
9
9
|
long_desc Help.text("docker:build")
|
|
10
10
|
option :push, type: :boolean, default: false
|
|
11
11
|
def build
|
|
@@ -14,7 +14,7 @@ module Ufo
|
|
|
14
14
|
push if options[:push]
|
|
15
15
|
end
|
|
16
16
|
|
|
17
|
-
desc "push IMAGE", "
|
|
17
|
+
desc "push IMAGE", "Push the docker image."
|
|
18
18
|
long_desc Help.text("docker:push")
|
|
19
19
|
option :push, type: :boolean, default: false
|
|
20
20
|
def push(full_image_name=nil)
|
|
@@ -23,7 +23,7 @@ module Ufo
|
|
|
23
23
|
pusher.push
|
|
24
24
|
end
|
|
25
25
|
|
|
26
|
-
desc "base", "
|
|
26
|
+
desc "base", "Build docker image from `Dockerfile.base` and update current `Dockerfile`."
|
|
27
27
|
long_desc Help.text("docker:base")
|
|
28
28
|
option :push, type: :boolean, default: true
|
|
29
29
|
def base
|
|
@@ -38,7 +38,7 @@ module Ufo
|
|
|
38
38
|
Ecr::Cleaner.new(builder.image_name, options.merge(tag_prefix: "base")).cleanup
|
|
39
39
|
end
|
|
40
40
|
|
|
41
|
-
desc "name", "
|
|
41
|
+
desc "name", "Display the full docker image with tag that was last generated."
|
|
42
42
|
option :generate, type: :boolean, default: false, desc: "Generate a name without storing it"
|
|
43
43
|
long_desc Help.text("docker:name")
|
|
44
44
|
def name
|
|
@@ -46,7 +46,7 @@ module Ufo
|
|
|
46
46
|
puts full_image_name
|
|
47
47
|
end
|
|
48
48
|
|
|
49
|
-
desc "clean IMAGE_NAME", "
|
|
49
|
+
desc "clean IMAGE_NAME", "Clean up old images. Keeps a specified amount."
|
|
50
50
|
option :keep, type: :numeric, default: 3
|
|
51
51
|
option :tag_prefix, default: "ufo"
|
|
52
52
|
long_desc Help.text("docker:clean")
|
data/lib/ufo/ecr/auth.rb
CHANGED
|
@@ -28,8 +28,13 @@ module Ufo
|
|
|
28
28
|
data = JSON.load(IO.read(docker_config))
|
|
29
29
|
data["auths"][@repo_domain] = {auth: auth_token}
|
|
30
30
|
else
|
|
31
|
-
data = {auths
|
|
31
|
+
data = {"auths" => {@repo_domain => {auth: auth_token}}}
|
|
32
32
|
end
|
|
33
|
+
|
|
34
|
+
# Handle legacy docker clients that still have old format with https://
|
|
35
|
+
legacy_entry = "https://#{@repo_domain}"
|
|
36
|
+
data["auths"][legacy_entry] = {auth: auth_token}
|
|
37
|
+
|
|
33
38
|
ensure_dotdocker_exists
|
|
34
39
|
IO.write(docker_config, JSON.pretty_generate(data))
|
|
35
40
|
end
|
data/lib/ufo/ecr/cleaner.rb
CHANGED
data/lib/ufo/help/completion.md
CHANGED
data/lib/ufo/help/completions.md
CHANGED
data/lib/ufo/help/deploy.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
It is useful to sometimes deploy only the task definition without re-building it. Say for example, you are debugging the task definition and just want to directly edit the `.ufo/output/hi-web.json` definition. You can accomplish this with the `ufo deploy` command. The `ufo deploy` command will deploy the task definition in `.ufo/output` unmodified. Example:
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
ufo deploy hi-web
|
|
4
4
|
|
|
5
5
|
The above command does the following:
|
|
6
6
|
|
|
@@ -12,3 +12,7 @@ The `ufo deploy` command does less than the `ufo ship` command. Typically, peop
|
|
|
12
12
|
1. build the Docker image
|
|
13
13
|
2. register the ECS task definition
|
|
14
14
|
3. update the ECS service
|
|
15
|
+
|
|
16
|
+
The `ufo ships`, `ufo ship`, `ufo deploy` command support the same options. The options are presented here again for convenience:
|
|
17
|
+
|
|
18
|
+
{% include ufo-ship-options.md %}
|
data/lib/ufo/help/destroy.md
CHANGED
|
@@ -1,5 +1,9 @@
|
|
|
1
|
-
Examples
|
|
1
|
+
## Examples
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Ufo provides a quick way to destroy an ECS service. To destroy an ECS service, you must make sure that the desired number of tasks is first set to 0. It is easy to forget to do this and waste time. So as part of destroying the service ufo will scale the ECS service down to 0 automatically first and then destroys the service. Ufo also prompts you before destroying the service.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
ufo destroy hi-web
|
|
6
|
+
|
|
7
|
+
If you would like to bypass the prompt, you can use the `--sure` option.
|
|
8
|
+
|
|
9
|
+
ufo destroy hi-web --sure
|
data/lib/ufo/help/docker.md
CHANGED
data/lib/ufo/help/docker/base.md
CHANGED
|
@@ -1,9 +1,39 @@
|
|
|
1
|
-
The docker cache task builds a docker image using the Dockerfile.base file and
|
|
2
|
-
updates the FROM Dockerfile image with the generated image from Dockerfile.base
|
|
1
|
+
The docker cache task builds a docker image using the `Dockerfile.base` file and
|
|
2
|
+
updates the FROM `Dockerfile` image with the generated image from `Dockerfile.base`.
|
|
3
3
|
|
|
4
|
-
|
|
4
|
+
## Summarized Example
|
|
5
5
|
|
|
6
6
|
ufo docker base
|
|
7
7
|
ufo docker base --no-push # do not push the image to the registry
|
|
8
8
|
|
|
9
|
-
Docker image tongueroo/hi:base-2016-10-21T15-50-57-88071f5 built.
|
|
9
|
+
Docker image `tongueroo/hi:base-2016-10-21T15-50-57-88071f5` built.
|
|
10
|
+
|
|
11
|
+
## Concept
|
|
12
|
+
|
|
13
|
+
Docker is fantastic and has given developers more power and control over the OS their application runs on. Sometimes building Docker images can be slow though. Docker layer caching technology helps immensely to speed up the process as Docker will only rebuild layers that require rebuilding. But sometimes one little dependency changes it results in having to rebuild many layers.
|
|
14
|
+
|
|
15
|
+
The `ufo docker base` commands allows you to build an Docker image from `Dockerfile.base` to be used as a cache and in the FROM instruction in the main `Dockerfile`. This base Docker cache image technique speeds up development substantially if you have dependencies like gems in your project. Let's say you have 20 gems in your project and are actively developing your project. You are experimenting with 3 different gems, adding and removing them while you are investigating the best gem to use. Without the Docker image cache that already has all of your other gems installed each time you adjust `Gemfile` it would have to wait until all the gems from scratch again installed again.
|
|
16
|
+
|
|
17
|
+
There are pros and cons of using this approach. Remember there are 2 hard problems in computer science: 1. Naming and 2. Caching. The main con about this approach is if you forget to update the base Docker image you will have cached artifacts that will not disappear unless you rebuild the base Docker image. While some folks are completely against introducing this cache layer, some have found it being a huge win in speeding up their Docker development workflow. If you are using this technique it is recommended that you set up some automation that rebuilds the base Docker image at least nightly.
|
|
18
|
+
|
|
19
|
+
## Demo
|
|
20
|
+
|
|
21
|
+
To demonstrate this command, there's a `docker-cache` branch in the [tongueroo/hi](https://github.com/tongueroo/hi/tree/docker-cache) repo.
|
|
22
|
+
|
|
23
|
+
Let's see the command in action:
|
|
24
|
+
|
|
25
|
+
ufo docker base
|
|
26
|
+
Building docker image with:
|
|
27
|
+
docker build -t tongueroo/hi:base-2017-06-12T14-36-44-2af505e -f Dockerfile.base .
|
|
28
|
+
...
|
|
29
|
+
Pushed tongueroo/hi:base-2017-06-12T14-36-44-2af505e docker image. Took 28s.
|
|
30
|
+
The Dockerfile FROM statement has been updated with the latest base image:
|
|
31
|
+
tongueroo/hi:base-2017-06-12T14-36-44-2af505e
|
|
32
|
+
|
|
33
|
+
Some of the output has been excluded so we can focus on the important parts to point out. First notice that the commmand simply shells out to the docker command and calls:
|
|
34
|
+
|
|
35
|
+
docker build -t tongueroo/hi:base-2017-06-12T14-36-44-2af505e -f Dockerfile.base .
|
|
36
|
+
|
|
37
|
+
It is using the docker `-f Dockerfile.base` option to build the base image. It names the image with `tongueroo/hi:base-2017-06-12T14-36-44-2af505e`. The image tag contains useful information: the timestamp when the image was built and the exact git sha of the code. The image gets push to a registry immediately.
|
|
38
|
+
|
|
39
|
+
Notice at the very end, the *current* `Dockerfile`'s FROM statement has been updated with the newly built base Docker image automatically. This saves you from forgetting to copying and pasting it the `Dockerfile` yourself.
|
|
@@ -1,6 +1,61 @@
|
|
|
1
|
-
|
|
1
|
+
The `ufo docker build` builds a Docker image using the Dockerfile in the current project folder. This simply is a wrapper command that shells out and calls the `docker` command. We're use the [tongueroo/hi](https://github.com/tongueroo/hi) project and it's Dockerfile for demonstration. Example:
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
|
|
3
|
+
ufo docker build
|
|
4
|
+
|
|
5
|
+
You'll see that it calls:
|
|
6
|
+
|
|
7
|
+
docker build -t tongueroo/hi:ufo-2017-06-11T22-18-03-a18aa30 -f Dockerfile .
|
|
8
|
+
|
|
9
|
+
You should see similar output (some of the output has been truncated for conciseness):
|
|
10
|
+
|
|
11
|
+
$ ufo docker build
|
|
12
|
+
Building docker image with:
|
|
13
|
+
docker build -t tongueroo/hi:ufo-2017-06-11T22-18-03-a18aa30 -f Dockerfile .
|
|
14
|
+
Sending build context to Docker daemon 734.2 kB
|
|
15
|
+
Step 1 : FROM ruby:2.3.3
|
|
16
|
+
---> 0e1db669d557
|
|
17
|
+
Step 2 : RUN apt-get update && apt-get install -y build-essential nodejs && rm -rf /var/lib/apt/lists/* && apt-get clean && apt-get purge
|
|
18
|
+
---> Using cache
|
|
19
|
+
---> 931ace833716
|
|
20
|
+
...
|
|
21
|
+
Step 7 : ADD . /app
|
|
22
|
+
---> fae2452e6c35
|
|
23
|
+
Removing intermediate container 4c93f92a7fd8
|
|
24
|
+
Step 8 : RUN bundle install --system
|
|
25
|
+
---> Running in f851b9cb7d27
|
|
26
|
+
Using rake 12.0.0
|
|
27
|
+
Using i18n 0.8.1
|
|
28
|
+
...
|
|
29
|
+
Using web-console 2.3.0
|
|
30
|
+
Bundle complete! 12 Gemfile dependencies, 56 gems now installed.
|
|
31
|
+
Bundled gems are installed into /usr/local/bundle.
|
|
32
|
+
---> 194830c5c1a8
|
|
33
|
+
...
|
|
34
|
+
Removing intermediate container 67545cd4cd09
|
|
35
|
+
Step 11 : CMD bin/web
|
|
36
|
+
---> Running in b1b26e68d957
|
|
37
|
+
---> 8547bb48b21f
|
|
38
|
+
Removing intermediate container b1b26e68d957
|
|
39
|
+
Successfully built 8547bb48b21f
|
|
40
|
+
Docker image tongueroo/hi:ufo-2017-06-11T22-18-03-a18aa30 built. Took 33s.
|
|
41
|
+
$
|
|
42
|
+
|
|
43
|
+
The docker image tag that is generated contains a useful timestamp and the current HEAD git sha of the project that you are on.
|
|
44
|
+
|
|
45
|
+
By default when you are running `ufo docker build` directly it does not push the docker image to the registry. If you would like it to automaticaly push the built image to a registry at the end of the build use the `--push` flag.
|
|
46
|
+
|
|
47
|
+
ufo docker build --push
|
|
48
|
+
|
|
49
|
+
You should see it being pushed at the end:
|
|
50
|
+
|
|
51
|
+
Docker image tongueroo/hi:ufo-2017-06-11T22-22-32-a18aa30 built. Took 34s.
|
|
52
|
+
The push refers to a repository [docker.io/tongueroo/hi]
|
|
53
|
+
ef375857f165: Pushed
|
|
54
|
+
4d791d7cde66: Pushed
|
|
55
|
+
277ff31e79b4: Layer already exists
|
|
56
|
+
a361a4de05df: Layer already exists
|
|
57
|
+
ufo-2017-06-11T22-22-32-a18aa30: digest: sha256:c5385a5084e87643bd943eb120e110321c59e8acd30736ba7b5223eb1143baa8 size: 3464
|
|
58
|
+
Pushed tongueroo/hi:ufo-2017-06-11T22-22-32-a18aa30 docker image. Took 9s.
|
|
59
|
+
|
|
60
|
+
Note in order to push the image to a registry you will need to login into the registry. If you are using DockerHub use the `docker login` command. If you are using AWS ECR then you can use the `aws ecr get-login` command.
|
|
5
61
|
|
|
6
|
-
Docker image tongueroo/hi:ufo-2016-10-21T15-50-57-88071f5 built.
|
|
@@ -1,14 +1,20 @@
|
|
|
1
|
-
|
|
1
|
+
Ufo comes with a handy command to clean up old images that ufo generates. Ufo only deletes images from the docker daemon and does not remove any images from any registry. To use it you pass the base portion of the image name to the command.
|
|
2
2
|
|
|
3
3
|
Say you currently have these images:
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
5
|
+
tongueroo/hi:ufo-2016-10-15T19-29-06-88071f5
|
|
6
|
+
tongueroo/hi:ufo-2016-10-16T19-29-06-88071f5
|
|
7
|
+
tongueroo/hi:ufo-2016-10-17T19-29-06-88071f5
|
|
8
|
+
tongueroo/hi:ufo-2016-10-18T19-29-06-88071f5
|
|
9
9
|
|
|
10
10
|
To clean them up and keep the 3 more recent:
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
$ ufo docker clean tongueroo/hi
|
|
13
|
+
Cleaning up docker images...
|
|
14
|
+
Running: docker rmi tongueroo/hi:ufo-2016-10-15T19-29-06-88071f5
|
|
13
15
|
|
|
14
16
|
This will remove tongueroo/hi:ufo-2016-10-15T19-29-06-88071f5.
|
|
17
|
+
|
|
18
|
+
By default the clean command keeps the most 3 recent docker images. If you would like to override this setting you can use the `--keep` option. Example:
|
|
19
|
+
|
|
20
|
+
ufo docker clean tongueroo/hi --keep 5
|
data/lib/ufo/help/docker/name.md
CHANGED
|
@@ -1,16 +1,16 @@
|
|
|
1
|
-
|
|
1
|
+
It is sometimes handy to grab the name of the Docker image that was just generated. Let's say ou needed the image name so you can feed it into another script that you have. The command `ufo docker name` returns the image of the most recently built Docker image.
|
|
2
2
|
|
|
3
|
-
Examples
|
|
3
|
+
## Examples
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
|
|
5
|
+
ufo docker build # stores the docker image name in the .ufo/data folder
|
|
6
|
+
ufo docker name # fetches image name from .ufo/data folder
|
|
7
7
|
|
|
8
|
-
An example image name would look something like this: tongueroo/hi:ufo-2018-02-15T19-29-06-88071f5
|
|
8
|
+
An example image name would look something like this: `tongueroo/hi:ufo-2018-02-15T19-29-06-88071f5`
|
|
9
9
|
|
|
10
|
-
Note, the
|
|
10
|
+
Note, the `.ufo/data` folder is an internal data folder and it's structure can change in future releases.
|
|
11
11
|
|
|
12
|
-
If you want to generate a brand new name for whatever purpose, you can use the `--generate` flag. The generate does not write to the `.ufo/data` folder. It only generates a fresh name to stdout. If you run it multiple times, it will generate new names. You can notice this by seeing that the timestamp will always update
|
|
12
|
+
If you want to generate a brand new name for whatever purpose, you can use the `--generate` flag. The generate does not write to the `.ufo/data` folder. It only generates a fresh name to stdout. If you run it multiple times, it will generate new names. You can notice this by seeing that the timestamp will always update:
|
|
13
13
|
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
14
|
+
ufo docker name --generate # example: tongueroo/hi:ufo-2018-02-15T10-00-00-88071f5
|
|
15
|
+
ufo docker name --generate # example: tongueroo/hi:ufo-2018-02-15T10-00-08-88071f5
|
|
16
|
+
ufo docker name --generate # example: tongueroo/hi:ufo-2018-02-15T10-00-16-88071f5
|
data/lib/ufo/help/docker/push.md
CHANGED
|
@@ -1,11 +1,28 @@
|
|
|
1
|
-
This command pushes a docker image up to the registry. By default it pushes the last image that was built with `ufo docker build`. To see what the image name is you can run `ufo docker name`. Example:
|
|
2
1
|
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
2
|
+
The `ufo docker push` command pushes the most recent Docker image built by `ufo docker build` to a registry. This command pushes a docker image up to the registry. By default it pushes the last image that was built with `ufo docker build`. To see what the image name is you can run `ufo docker name`. Example:
|
|
3
|
+
|
|
4
|
+
ufo docker build # to build the image
|
|
5
|
+
ufo docker name # to see the image name
|
|
6
|
+
ufo docker push # push up the registry
|
|
7
|
+
|
|
8
|
+
You'll see that `ufo docker push` simply shells out and calls `docker push`:
|
|
9
|
+
|
|
10
|
+
$ ufo docker push
|
|
11
|
+
=> docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/hi:ufo-2018-02-13T10-51-44-e0cc7be
|
|
12
|
+
The push refers to a repository [123456789.dkr.ecr.us-east-1.amazonaws.com/hi]
|
|
13
|
+
399c739c257d: Layer already exists
|
|
14
|
+
...
|
|
15
|
+
Pushed 123456789.dkr.ecr.us-east-1.amazonaws.com/hi:ufo-2018-02-13T10-51-44-e0cc7be docker image. Took 1s.
|
|
16
|
+
$
|
|
6
17
|
|
|
7
18
|
You can also push up a custom image by specifying the image name as the first parameter.
|
|
8
19
|
|
|
9
|
-
|
|
20
|
+
ufo docker push my/image:tag
|
|
21
|
+
|
|
22
|
+
You could also use the `--push` flag as part of the `ufo docker build` command to achieve the same thing as `ufo docker push`. The `ufo docker push` command might be more intutitive.
|
|
23
|
+
|
|
24
|
+
ufo docker build --push # same as above
|
|
25
|
+
|
|
26
|
+
## Docker Authorization
|
|
10
27
|
|
|
11
|
-
|
|
28
|
+
Note in order to push the image to a registry you will need to login into the registry. If you are using DockerHub use the `docker login` command. If you are using AWS ECR then, ufo will automatically try to authorize you and configure your `~/.docker/config.json`. If can also use `aws ecr get-login` command.
|
data/lib/ufo/help/hello.md
CHANGED
data/lib/ufo/help/init.md
CHANGED
|
@@ -1,11 +1,49 @@
|
|
|
1
|
-
|
|
1
|
+
The `ufo init` command provides a way to quickly setup a project to be ufo ready. It creates a ufo folder with all the starter supporting files in order to use ufo. This page demonstrates how to use `ufo init`. The command requires these options: `--app` and `--image`.
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
## Examples
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
For this example we will use [tongueroo/hi](https://github.com/tongueroo/hi) which is a small test sinatra app. Let's run the command in our newly clone project.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
$ git clone https://github.com/tongueroo/hi.git
|
|
8
|
+
$ cd hi
|
|
9
|
+
$ ufo init --app=hi --image=tongueroo/hi
|
|
10
|
+
Setting up ufo project...
|
|
11
|
+
create .ufo/settings.yml
|
|
12
|
+
create .ufo/task_definitions.rb
|
|
13
|
+
create .ufo/templates/main.json.erb
|
|
14
|
+
create .ufo/variables/base.rb
|
|
15
|
+
create .ufo/variables/development.rb
|
|
16
|
+
create .ufo/variables/production.rb
|
|
17
|
+
create Dockerfile
|
|
18
|
+
create bin/deploy
|
|
19
|
+
append .gitignore
|
|
20
|
+
Starter ufo files created.
|
|
8
21
|
|
|
9
|
-
|
|
22
|
+
## Options: app and image
|
|
23
|
+
|
|
24
|
+
The `app` is that application name that you want to show up on the ECS dashboard. It is encouraged to have the app name be a single word.
|
|
25
|
+
|
|
26
|
+
The `image` is the base portion of image name that will be pushed to the docker registry, ie: DockerHub or AWS ECR. The image should **not** include the tag since the tag is generated upon a `ufo ship`. For example:
|
|
27
|
+
|
|
28
|
+
tongueroo/hi => tongueroo/hi:ufo-2018-02-08T21-04-02-3c86158
|
|
10
29
|
|
|
11
30
|
The generated `tongueroo/hi:ufo-2018-02-08T21-04-02-3c86158` image name gets pushed to the docker registry.
|
|
31
|
+
|
|
32
|
+
## Directory Structure
|
|
33
|
+
|
|
34
|
+
The standard directory structure of the `.ufo` folder that was created looks like this:
|
|
35
|
+
|
|
36
|
+
ufo
|
|
37
|
+
├── output
|
|
38
|
+
├── settings.yml
|
|
39
|
+
├── task_definitions.rb
|
|
40
|
+
├── templates
|
|
41
|
+
├ └── main.json.erb
|
|
42
|
+
└── variables
|
|
43
|
+
├── base.rb
|
|
44
|
+
├── production.rb
|
|
45
|
+
└── development.rb
|
|
46
|
+
|
|
47
|
+
For a explanation of the folders and files refer to [Structure]({% link _docs/structure.md %}).
|
|
48
|
+
|
|
49
|
+
|
data/lib/ufo/help/scale.md
CHANGED
|
@@ -1,5 +1,6 @@
|
|
|
1
|
-
|
|
1
|
+
Ufo provides a command to scale up and down an ECS service quickly. It is a simple wrapper for `aws ecs update-service --service xxx ----desired-count xxx`. Here's an example of how you use it:
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
$ ufo scale hi-web 3
|
|
4
|
+
Scale hi-web service in stag cluster to 3
|
|
4
5
|
|
|
5
|
-
|
|
6
|
+
While scaling via this method is quick and convenient the [ECS Service AutoScaling](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) that is built into ECS is a much more powerful way to manage scaling your ECS service.
|
data/lib/ufo/help/ship.md
CHANGED
|
@@ -1,17 +1,68 @@
|
|
|
1
|
-
|
|
1
|
+
The main command you use when using ufo is: `ufo ship`. This command:
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
1. builds the docker image
|
|
4
|
+
2. registers the generated ECS task definition
|
|
5
|
+
3. deploys the definition to AWS ECS
|
|
4
6
|
|
|
5
|
-
|
|
7
|
+
Basic usage is:
|
|
8
|
+
|
|
9
|
+
ufo ship hi-web
|
|
10
|
+
|
|
11
|
+
The ECS service gets created if the service does not yet exist on the cluster.
|
|
12
|
+
|
|
13
|
+
### Conventions
|
|
6
14
|
|
|
7
15
|
By convention the task and service names match. If you need override to this convention then you can specific the task. For example if you want to ship to the `hi-web-1` service and use the `hi-web` task, run:
|
|
8
16
|
|
|
9
|
-
|
|
17
|
+
ufo ship hi-web-1 --task hi-web
|
|
18
|
+
|
|
19
|
+
## Options in Detail
|
|
20
|
+
|
|
21
|
+
The command has a decent amount of options, you can see the options available with `ufo ship -h`. The table below covers some of the options in detail:
|
|
22
|
+
|
|
23
|
+
{% include ufo-ship-options.md %}
|
|
24
|
+
|
|
25
|
+
As you can see there are plenty of options for `ufo ship`. Let's demonstrate usage of them in a few examples.
|
|
26
|
+
|
|
27
|
+
### Load Balancer Target Group
|
|
28
|
+
|
|
29
|
+
When you are deploying to a service with the word 'web' in it, ufo assumes that this is a web service that uses a load balancer in front of it. This is also covered a in the [Conventions]({% link _docs/conventions.md %}) page. The deploy will prompt you for the ELB `--target-group` if the ECS does not yet exist. For non-web container the `--target-group` option gets ignored. The prommpt can be bypassed by specifying a valid `--target-group` option or specifying the `---no-target-group-prompt` option.
|
|
30
|
+
|
|
31
|
+
ufo ship hi-web --no-target-group-prompt
|
|
32
|
+
|
|
33
|
+
Or if you would like to specify the target-group upfront and not be bother with the prompted later you can use the `--target-group` option.
|
|
34
|
+
|
|
35
|
+
ufo ship hi-web --target-group=arn:aws:elasticloadbalancing:us-east-1:12345689:targetgroup/hi-web/12345
|
|
36
|
+
|
|
37
|
+
### Deploying Task Definition without Docker Build
|
|
38
|
+
|
|
39
|
+
Let's you want skip the docker build phase and only want use ufo to deploy a task definition. You can do this with the `ufo deploy` command. Refer to [ufo deploy](http://ufoships.com/reference/ufo-deploy/) for more info.
|
|
40
|
+
|
|
41
|
+
### Waiting for Deployments to Complete
|
|
42
|
+
|
|
43
|
+
By default when ufo updates the ECS service with the new task definition it does so asynchronuously. You then normally visit the ECS service console and then refresh until you see that the deployment is completed. You can also have ufo poll and wait for the deployment to be done with the `--wait` option
|
|
44
|
+
|
|
45
|
+
ufo ship hi-web --wait
|
|
46
|
+
|
|
47
|
+
You should see output similar to this:
|
|
48
|
+
|
|
49
|
+
Shipping hi-web...
|
|
50
|
+
hi-web service updated on cluster with task hi-web
|
|
51
|
+
Waiting for deployment of task definition hi-web:8 to complete
|
|
52
|
+
......
|
|
53
|
+
Time waiting for ECS deployment: 31s.
|
|
54
|
+
Software shipped!
|
|
55
|
+
|
|
56
|
+
### Cleaning up Docker Images Automatically
|
|
57
|
+
|
|
58
|
+
Since ufo builds the Docker image every time there's a deployment you will end up with a long list of docker images. Ufo automatically cleans up older docker images at the end of the deploy process if you are using AWS ECR. By default ufo keeps the most recent 30 Docker images. This can be adjust with the `--ecr-keep` option.
|
|
59
|
+
|
|
60
|
+
docker ship hi-web --ecr-keep 2
|
|
10
61
|
|
|
11
|
-
|
|
62
|
+
You should see something like this:
|
|
12
63
|
|
|
13
|
-
|
|
64
|
+
Cleaning up docker images...
|
|
65
|
+
Running: docker rmi tongueroo/hi:ufo-2017-06-12T06-46-12-a18aa30
|
|
14
66
|
|
|
15
|
-
|
|
67
|
+
If you are using DockerHub or another registry, ufo does not automatically clean up images.
|
|
16
68
|
|
|
17
|
-
ufo ship hi-web --no-target-group-prompt
|