Skip to content

Commit 546fef4

Browse files
committed
fix addig secrets and envs, ecr notes
1 parent 48cb2d0 commit 546fef4

File tree

1 file changed

+15
-22
lines changed
  • adminforth/documentation/blog/2025-02-19-compose-ec2-deployment-ci-registry

1 file changed

+15
-22
lines changed

adminforth/documentation/blog/2025-02-19-compose-ec2-deployment-ci-registry/index.md

Lines changed: 15 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -70,11 +70,12 @@ Of course you have to care about a way of registry authentication (so only you a
7070

7171
What docker registry can you use? Pretty known options:
7272
1) Docker Hub - most famous. It is free for public images, so literally every opensource project uses it. However it is not free for private images, and you have to pay for it. In this post we are considering you might do development for commercial project with tight budget, so we will not use it.
73-
2) GHCR - Registry from Google. Has free plan but allows to store only 500MB and allows to transfer 1GB of traffic per month. Then you pay for every extra GB in storage and traffic. Probably small images will fit in this plan, but generally even alpine-based docker images are bigger than 500MB, so it is not a good option.
74-
3) Self-hosted registry web system. In our software development company, we use Harbor. It is a powerful free open-source registry that can be installed to own server. It allows pushing and pulling without limit. Also, it has internal life-cycle rules that cleanup unnecessary images and layers. The main drawbacks of it are that it is not so fast to install and configure, plus you have to get a domain and another powerfull server to run it. So unless you are a software development company, it is not worth using it.
75-
4) Self-hosted minimal CNCF Distribution [registry](https://distribution.github.io/distribution/) on EC2 itself. So since we already have EC2, we can run registry on it directly. The `registry` container is pretty light-weight and easy to setup and it will not consume a lot of extra CPU/RAM on server. Plus images will be stored close to application so pull will be fast.
73+
2) GHCR - Registry from GitHub. Has free plan but allows to store only 500MB and allows to transfer 1GB of traffic per month. Then you pay for every extra GB in storage (`$0.0008` per GB/day or `$0.24` per GB/month) and for every extra GB in traffic ($0.09 per GB). Probably small images will fit in free plan, but generally even alpine-based docker images are bigger than 500MB, so it is non-free option.
74+
3) Amazon ECR - Same as GHCR but from Amazon. Price is `$0.10` per GB of storage per month and `$0.09` per GB of data transfer. So it is cheaper than GHCR but still not free. But is good option.
75+
4) Self-hosted registry web system. In our software development company, we use Harbor. It is a powerful free open-source registry that can be installed to own server. It allows pushing and pulling without limit. Also, it has internal life-cycle rules that cleanup unnecessary images and layers. The main drawbacks of it are that it is not so fast to install and configure, plus you have to get a domain and another powerfull server to run it. So unless you are a software development company, it is not worth using it.
76+
5) Self-hosted minimal CNCF Distribution [registry](https://distribution.github.io/distribution/) on EC2 itself. So since we already have EC2, we can run registry on it directly. The `registry` container is pretty light-weight and easy to setup and it will not consume a lot of extra CPU/RAM on server. Plus images will be stored close to application so pull will be fast.
7677

77-
In the post we will use last (4th way). Our terraform will deploy registry automatically, so you don't have to do anything special.
78+
In the post we will use last (5th way). Our terraform will deploy registry automatically, so you don't have to do anything special.
7879

7980
### Persisting cache
8081

@@ -687,6 +688,10 @@ jobs:
687688
VAULT_AWS_ACCESS_KEY_ID: ${{ secrets.VAULT_AWS_ACCESS_KEY_ID }}
688689
VAULT_AWS_SECRET_ACCESS_KEY: ${{ secrets.VAULT_AWS_SECRET_ACCESS_KEY }}
689690
691+
- name: Prepare env
692+
run: |
693+
echo "" > deploy/.env.live
694+
690695
- name: Terraform build
691696
run: |
692697
cd deploy
@@ -729,27 +734,15 @@ Open your GitHub repository, then `Settings` -> `Secrets` -> `New repository sec
729734
Now open GitHub actions file and add it to the `env` section:
730735

731736
```yml title=".github/workflows/deploy.yml"
732-
- name: Start building
733-
env:
734-
VAULT_AWS_ACCESS_KEY_ID: ${{ secrets.VAULT_AWS_ACCESS_KEY_ID }}
735-
VAULT_AWS_SECRET_ACCESS_KEY: ${{ secrets.VAULT_AWS_SECRET_ACCESS_KEY }}
736-
VAULT_SSH_PRIVATE_KEY: ${{ secrets.VAULT_SSH_PRIVATE_KEY }}
737-
VAULT_SSH_PUBLIC_KEY: ${{ secrets.VAULT_SSH_PUBLIC_KEY }}
738-
//diff-add
739-
VAULT_OPENAI_API_KEY: ${{ secrets.VAULT_OPENAI_API_KEY }}
740-
```
741-
742-
Next add it to the `deploy.sh` script:
743-
744-
```sh title="deploy/deploy.sh"
745-
//diff-remove
746-
echo "" > .env.live
737+
- name: Prepare env
738+
run: |
739+
echo "" > deploy/.env.live
747740
//diff-add
748-
cat <<EOF > .env.live
741+
echo "OPENAI_API_KEY=$VAULT_OPENAI_API_KEY" >> deploy/.env.live
749742
//diff-add
750-
OPENAI_API_KEY=$VAULT_OPENAI_API_KEY
743+
env:
751744
//diff-add
752-
EOF
745+
VAULT_OPENAI_API_KEY: ${{ secrets.VAULT_OPENAI_API_KEY }}
753746
```
754747

755748

0 commit comments

Comments
 (0)