diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-16 12:09:12 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-16 12:09:12 +0000 |
commit | cbfe03ae04a52d9825ff7cbeccdfe5d313adf6a2 (patch) | |
tree | e4879b35d019d3bbba1689f3ac4c48b81bf7b451 /doc | |
parent | 3fd97b4bba24ca412112aad025a38a32c7a6cf8c (diff) | |
download | gitlab-ce-cbfe03ae04a52d9825ff7cbeccdfe5d313adf6a2.tar.gz |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r-- | doc/api/releases/index.md | 2 | ||||
-rw-r--r-- | doc/ci/cloud_deployment/index.md | 58 | ||||
-rw-r--r-- | doc/ci/img/ecs_dashboard_v12_9.png | bin | 0 -> 109395 bytes | |||
-rw-r--r-- | doc/development/elasticsearch.md | 6 |
4 files changed, 60 insertions, 6 deletions
diff --git a/doc/api/releases/index.md b/doc/api/releases/index.md index ffd4efdca5d..6e98076b7e2 100644 --- a/doc/api/releases/index.md +++ b/doc/api/releases/index.md @@ -328,7 +328,7 @@ POST /projects/:id/releases | `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). | | `name` | string | no | The release name. | | `tag_name` | string | yes | The tag where the release will be created from. | -| `description` | string | yes | The description of the release. You can use [Markdown](../../user/markdown.md). | +| `description` | string | no | The description of the release. You can use [Markdown](../../user/markdown.md). | | `ref` | string | yes, if `tag_name` doesn't exist | If `tag_name` doesn't exist, the release will be created from `ref`. It can be a commit SHA, another tag name, or a branch name. | | `milestones` | array of string | no | The title of each milestone the release is associated with. | | `assets:links` | array of hash | no | An array of assets links. | diff --git a/doc/ci/cloud_deployment/index.md b/doc/ci/cloud_deployment/index.md index ccb6b60ecc9..ccff302750c 100644 --- a/doc/ci/cloud_deployment/index.md +++ b/doc/ci/cloud_deployment/index.md @@ -61,3 +61,61 @@ To do so, please make sure to [push your image into your ECR repository](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html) before referencing it in your `.gitlab-ci.yml` file and replace the `image` path to point to your ECR. + +### Deploy your application to AWS Elastic Container Service (ECS) + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/207962) in GitLab 12.9. + +GitLab provides a series of [CI templates that you can include in your project](../yaml/README.md#include). +To automate deployments of your application to your [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AWS ECS) +cluster, you can `include` the `Deploy-ECS.gitlab-ci.yml` template in your `.gitlab-ci.yml` file. + +Before getting started with this process, you need a cluster on AWS ECS, as well as related +components, like an ECS service, ECS task definition, a database on AWS RDS, etc. +[Read more about AWS ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html). + +After you're all set up on AWS ECS, follow these steps: + +1. Make sure your AWS credentials are set up as environment variables for your + project. You can follow [the steps above](#aws) to complete this setup. +1. Add these variables to your project's `.gitlab-ci.yml` file: + + ```yaml + variables: + CI_AWS_ECS_CLUSTER: my-cluster + CI_AWS_ECS_SERVICE: my-service + CI_AWS_ECS_TASK_DEFINITION: my-task-definition + ``` + + Three variables are defined in this snippet: + + - `CI_AWS_ECS_CLUSTER`: The name of your AWS ECS cluster that you're + targeting for your deployments. + - `CI_AWS_ECS_SERVICE`: The name of the targeted service tied to + your AWS ECS cluster. + - `CI_AWS_ECS_TASK_DEFINITION`: The name of the task definition tied + to the service mentioned above. + + You can find these names after selecting the targeted cluster on your [AWS ECS dashboard](https://console.aws.amazon.com/ecs/home): + + ![AWS ECS dashboard](../img/ecs_dashboard_v12_9.png) + +1. Include this template in `.gitlab-ci.yml`: + + ```yaml + include: + - template: Deploy-ECS.gitlab-ci.yml + ``` + + The `Deploy-ECS` template ships with GitLab and is available [on + GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Deploy-ECS.gitlab-ci.yml). + +1. Commit and push your updated `.gitlab-ci.yml` to your project's repository, and you're done! + + Your application Docker image will be rebuilt and pushed to the GitLab registry. + Then the targeted task definition will be updated with the location of the new + Docker image, and a new revision will be created in ECS as result. + + Finally, your AWS ECS service will be updated with the new revision of the + task definition, making the cluster pull the newest version of your + application. diff --git a/doc/ci/img/ecs_dashboard_v12_9.png b/doc/ci/img/ecs_dashboard_v12_9.png Binary files differnew file mode 100644 index 00000000000..bebd6f7903c --- /dev/null +++ b/doc/ci/img/ecs_dashboard_v12_9.png diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md index 69113fe8030..16a86c06317 100644 --- a/doc/development/elasticsearch.md +++ b/doc/development/elasticsearch.md @@ -36,11 +36,7 @@ Additionally, if you need large repos or multiple forks for testing, please cons The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb). -After initial indexing is complete, updates proceed in one of two ways, depending on the `:elastic_bulk_incremental_updates` feature flag. - -If disabled, every create, update, or delete operation on an Elasticsearch-tracked model enqueues a new `ElasticIndexerWorker` Sidekiq job which takes care of updating just that document. This is quite inefficient. - -If the feature flag is enabled, create, update, and delete operations for all models except projects (see [#207494](https://gitlab.com/gitlab-org/gitlab/issues/207494)) are tracked in a Redis [`ZSET`](https://redis.io/topics/data-types#sorted-sets) instead. A regular `sidekiq-cron` `ElasticIndexBulkCronWorker` processes this queue, updating many Elasticsearch documents at a time with the [Bulk Request API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html). +After initial indexing is complete, create, update, and delete operations for all models except projects (see [#207494](https://gitlab.com/gitlab-org/gitlab/issues/207494)) are tracked in a Redis [`ZSET`](https://redis.io/topics/data-types#sorted-sets). A regular `sidekiq-cron` `ElasticIndexBulkCronWorker` processes this queue, updating many Elasticsearch documents at a time with the [Bulk Request API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html). Search queries are generated by the concerns found in [ee/app/models/concerns/elastic](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them! |