diff options
Diffstat (limited to 'python-weco-deploy.spec')
| -rw-r--r-- | python-weco-deploy.spec | 471 |
1 files changed, 471 insertions, 0 deletions
diff --git a/python-weco-deploy.spec b/python-weco-deploy.spec new file mode 100644 index 0000000..5eef896 --- /dev/null +++ b/python-weco-deploy.spec @@ -0,0 +1,471 @@ +%global _empty_manifest_terminate_build 0 +Name: python-weco-deploy +Version: 5.7.4 +Release: 1 +Summary: A tool for deploying ECS services at the Wellcome Collection +License: MIT +URL: https://github.com/wellcomecollection/weco-deploy +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/33/c0/90c7caa2d2a56d0f8a14dea86dc8c49c74b44402777bd5e1a0fc39448173/weco-deploy-5.7.4.tar.gz +BuildArch: noarch + + +%description +# weco-deploy + +[](https://buildkite.com/wellcomecollection/deployment-cli-weco-deploy) + +weco-deploy helps us deploy applications as Docker images within Amazon ECS. + +This tool only makes sense in the context of how we tag and deploy images, so this README explains our broad approach and how we use weco-deploy. + + + +## How we tag our Docker images + +We package applications as Docker images. +Images are automatically pushed on every merge to a main branch, and pushed to an ECR repository. + +Within our ECR repository, we have three types of tag. +Here's a list of images, to serve as an example: + +<img src="./docs/ecr_tags.png" alt="A screenshot of the ECR console, showing a repo with five images."> + +Here's how we tag images: + +- Every image has a tag starting `ref`; this is the Git commit has that was used to build a given image. + This helps us match an image to its source code. + +- The `latest` tag points to the last image that was pushed to this repository. + It helps us know what the newest version of our code is. + + This tag is updated by our CI/CD pipeline. + +- The `env` tags point to the image being used in a particular environment. + For example, we can see here there are images with an `env.stage` and an `env.prod` tag – these are the images used in our staging and prod environment, respectively. + + These are floating tags set by weco-deploy. + + + +## How we use tags to deploy images + +Within our ECS task definitions, we point to an `env` tag as the Docker image to use. + +``` +{ + "containerDefinitions": [ + { + "image": "{ECR repository prefix}/our_app:env.stage", + ... + } + ], + ... +} +``` + +weco-deploy gives us tools for updating these floating `env` tags. +This is easiest to explain with some example scenarios: + +* Example #1: We've pushed some new code, and we want to deploy it to our staging environment. + + First our CI/CD pipeline builds new Docker images, publishes them to an ECR repository, and tags them with `latest`. + Then we ask weco-deploy to update the `env.stage` tag to point to the images that are currently tagged `latest`. + Finally, weco-deploy tells ECS to redeploy any services using that tag, which causes them to pull the new Docker image. + +* Example #2: We've tested the code in staging, we're satisfied it works, and we want to deploy it to production. + + First we ask weco-deploy to update the `env.prod` tag to point to the images that are currently tagged `env.stage`. + Then, weco-deploy tells ECS to redeploy any services using that tag, which causes them to pull the new Docker image. + +weco-deploy also tracks all the deployments, so we can see what code was deployed when. + + + +## Terminology + +These are the terms which are used by weco-deploy, which have a fairly specific meaning in this context: + +<dl> + <dt>project</dt> + <dd> + A collection of images/services that are deployed together. + Different projects are managed independently, e.g. we can deploy new images to the catalogue API without affecting the storage service. + </dd> + + <dt>release</dt> + <dd> + A set of specific versions of Docker images that can be deployed together. + e.g. The set of images `bag_verifier:ref.123`, `bag_replicator:ref.456` and `bag_unpacker:ref.789`. + </dd> + + <dt>deployment</dt> + <dd> + The act of applying a release to an environment. + i.e. telling ECS to use a particular set of images.<br/><br/> + A release is just an abstract concept; a deployment is making it concrete by deploying the images. + Note that one release might be used in multiple deployments: for example, deploying a release to a staging environment and then a production environment. + </dd> + + <dt>.wellcome_project file</dt> + <dd> + A YAML file that is used to configure weco-deploy: in particular, listing each project, the Docker images it contains, and what ECS services need to be redeployed when the image tags are updated. + The easiest way to understand is to <a href="https://github.com/wellcomecollection/catalogue-pipeline/blob/main/.wellcome_project">look at an example</a>. + </dd> +</dl> + + + +## Installation + +weco-deploy is published as a package to PyPI, so you can install it with pip: + +```console +$ pip3 install weco-deploy +``` + + + +## Usage + +Most of our use of weco-deploy is automated in Buildkite, so manual use is rare. + +The most useful subcommands are: + +``` +$ # create a new release, but don't deploy it +$ weco-deploy prepare + +$ # deploy a previously created release +$ weco-deploy deploy + +$ # create a new release and deploy it straight to ECS +$ weco-deploy release-deploy +``` + +You can select a project/label using command-line flags, or if not the tool will prompt you for the required inputs. + + +%package -n python3-weco-deploy +Summary: A tool for deploying ECS services at the Wellcome Collection +Provides: python-weco-deploy +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-weco-deploy +# weco-deploy + +[](https://buildkite.com/wellcomecollection/deployment-cli-weco-deploy) + +weco-deploy helps us deploy applications as Docker images within Amazon ECS. + +This tool only makes sense in the context of how we tag and deploy images, so this README explains our broad approach and how we use weco-deploy. + + + +## How we tag our Docker images + +We package applications as Docker images. +Images are automatically pushed on every merge to a main branch, and pushed to an ECR repository. + +Within our ECR repository, we have three types of tag. +Here's a list of images, to serve as an example: + +<img src="./docs/ecr_tags.png" alt="A screenshot of the ECR console, showing a repo with five images."> + +Here's how we tag images: + +- Every image has a tag starting `ref`; this is the Git commit has that was used to build a given image. + This helps us match an image to its source code. + +- The `latest` tag points to the last image that was pushed to this repository. + It helps us know what the newest version of our code is. + + This tag is updated by our CI/CD pipeline. + +- The `env` tags point to the image being used in a particular environment. + For example, we can see here there are images with an `env.stage` and an `env.prod` tag – these are the images used in our staging and prod environment, respectively. + + These are floating tags set by weco-deploy. + + + +## How we use tags to deploy images + +Within our ECS task definitions, we point to an `env` tag as the Docker image to use. + +``` +{ + "containerDefinitions": [ + { + "image": "{ECR repository prefix}/our_app:env.stage", + ... + } + ], + ... +} +``` + +weco-deploy gives us tools for updating these floating `env` tags. +This is easiest to explain with some example scenarios: + +* Example #1: We've pushed some new code, and we want to deploy it to our staging environment. + + First our CI/CD pipeline builds new Docker images, publishes them to an ECR repository, and tags them with `latest`. + Then we ask weco-deploy to update the `env.stage` tag to point to the images that are currently tagged `latest`. + Finally, weco-deploy tells ECS to redeploy any services using that tag, which causes them to pull the new Docker image. + +* Example #2: We've tested the code in staging, we're satisfied it works, and we want to deploy it to production. + + First we ask weco-deploy to update the `env.prod` tag to point to the images that are currently tagged `env.stage`. + Then, weco-deploy tells ECS to redeploy any services using that tag, which causes them to pull the new Docker image. + +weco-deploy also tracks all the deployments, so we can see what code was deployed when. + + + +## Terminology + +These are the terms which are used by weco-deploy, which have a fairly specific meaning in this context: + +<dl> + <dt>project</dt> + <dd> + A collection of images/services that are deployed together. + Different projects are managed independently, e.g. we can deploy new images to the catalogue API without affecting the storage service. + </dd> + + <dt>release</dt> + <dd> + A set of specific versions of Docker images that can be deployed together. + e.g. The set of images `bag_verifier:ref.123`, `bag_replicator:ref.456` and `bag_unpacker:ref.789`. + </dd> + + <dt>deployment</dt> + <dd> + The act of applying a release to an environment. + i.e. telling ECS to use a particular set of images.<br/><br/> + A release is just an abstract concept; a deployment is making it concrete by deploying the images. + Note that one release might be used in multiple deployments: for example, deploying a release to a staging environment and then a production environment. + </dd> + + <dt>.wellcome_project file</dt> + <dd> + A YAML file that is used to configure weco-deploy: in particular, listing each project, the Docker images it contains, and what ECS services need to be redeployed when the image tags are updated. + The easiest way to understand is to <a href="https://github.com/wellcomecollection/catalogue-pipeline/blob/main/.wellcome_project">look at an example</a>. + </dd> +</dl> + + + +## Installation + +weco-deploy is published as a package to PyPI, so you can install it with pip: + +```console +$ pip3 install weco-deploy +``` + + + +## Usage + +Most of our use of weco-deploy is automated in Buildkite, so manual use is rare. + +The most useful subcommands are: + +``` +$ # create a new release, but don't deploy it +$ weco-deploy prepare + +$ # deploy a previously created release +$ weco-deploy deploy + +$ # create a new release and deploy it straight to ECS +$ weco-deploy release-deploy +``` + +You can select a project/label using command-line flags, or if not the tool will prompt you for the required inputs. + + +%package help +Summary: Development documents and examples for weco-deploy +Provides: python3-weco-deploy-doc +%description help +# weco-deploy + +[](https://buildkite.com/wellcomecollection/deployment-cli-weco-deploy) + +weco-deploy helps us deploy applications as Docker images within Amazon ECS. + +This tool only makes sense in the context of how we tag and deploy images, so this README explains our broad approach and how we use weco-deploy. + + + +## How we tag our Docker images + +We package applications as Docker images. +Images are automatically pushed on every merge to a main branch, and pushed to an ECR repository. + +Within our ECR repository, we have three types of tag. +Here's a list of images, to serve as an example: + +<img src="./docs/ecr_tags.png" alt="A screenshot of the ECR console, showing a repo with five images."> + +Here's how we tag images: + +- Every image has a tag starting `ref`; this is the Git commit has that was used to build a given image. + This helps us match an image to its source code. + +- The `latest` tag points to the last image that was pushed to this repository. + It helps us know what the newest version of our code is. + + This tag is updated by our CI/CD pipeline. + +- The `env` tags point to the image being used in a particular environment. + For example, we can see here there are images with an `env.stage` and an `env.prod` tag – these are the images used in our staging and prod environment, respectively. + + These are floating tags set by weco-deploy. + + + +## How we use tags to deploy images + +Within our ECS task definitions, we point to an `env` tag as the Docker image to use. + +``` +{ + "containerDefinitions": [ + { + "image": "{ECR repository prefix}/our_app:env.stage", + ... + } + ], + ... +} +``` + +weco-deploy gives us tools for updating these floating `env` tags. +This is easiest to explain with some example scenarios: + +* Example #1: We've pushed some new code, and we want to deploy it to our staging environment. + + First our CI/CD pipeline builds new Docker images, publishes them to an ECR repository, and tags them with `latest`. + Then we ask weco-deploy to update the `env.stage` tag to point to the images that are currently tagged `latest`. + Finally, weco-deploy tells ECS to redeploy any services using that tag, which causes them to pull the new Docker image. + +* Example #2: We've tested the code in staging, we're satisfied it works, and we want to deploy it to production. + + First we ask weco-deploy to update the `env.prod` tag to point to the images that are currently tagged `env.stage`. + Then, weco-deploy tells ECS to redeploy any services using that tag, which causes them to pull the new Docker image. + +weco-deploy also tracks all the deployments, so we can see what code was deployed when. + + + +## Terminology + +These are the terms which are used by weco-deploy, which have a fairly specific meaning in this context: + +<dl> + <dt>project</dt> + <dd> + A collection of images/services that are deployed together. + Different projects are managed independently, e.g. we can deploy new images to the catalogue API without affecting the storage service. + </dd> + + <dt>release</dt> + <dd> + A set of specific versions of Docker images that can be deployed together. + e.g. The set of images `bag_verifier:ref.123`, `bag_replicator:ref.456` and `bag_unpacker:ref.789`. + </dd> + + <dt>deployment</dt> + <dd> + The act of applying a release to an environment. + i.e. telling ECS to use a particular set of images.<br/><br/> + A release is just an abstract concept; a deployment is making it concrete by deploying the images. + Note that one release might be used in multiple deployments: for example, deploying a release to a staging environment and then a production environment. + </dd> + + <dt>.wellcome_project file</dt> + <dd> + A YAML file that is used to configure weco-deploy: in particular, listing each project, the Docker images it contains, and what ECS services need to be redeployed when the image tags are updated. + The easiest way to understand is to <a href="https://github.com/wellcomecollection/catalogue-pipeline/blob/main/.wellcome_project">look at an example</a>. + </dd> +</dl> + + + +## Installation + +weco-deploy is published as a package to PyPI, so you can install it with pip: + +```console +$ pip3 install weco-deploy +``` + + + +## Usage + +Most of our use of weco-deploy is automated in Buildkite, so manual use is rare. + +The most useful subcommands are: + +``` +$ # create a new release, but don't deploy it +$ weco-deploy prepare + +$ # deploy a previously created release +$ weco-deploy deploy + +$ # create a new release and deploy it straight to ECS +$ weco-deploy release-deploy +``` + +You can select a project/label using command-line flags, or if not the tool will prompt you for the required inputs. + + +%prep +%autosetup -n weco-deploy-5.7.4 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-weco-deploy -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Wed May 31 2023 Python_Bot <Python_Bot@openeuler.org> - 5.7.4-1 +- Package Spec generated |