5/20/2023 0 Comments Heroku git add remote![]() Lastly, we will use curl inside a loop to wait until the first replica is alive and recreate the second one. Then with git -work-tree=$GIT_WORK_TREE -git-dir=$GIT_DIR checkout -f main we are copying the contents from that branch to our GIT_WORK_TREE folder ( appcode/). The line if ] is checking that we are pushing to the main branch (change it to master or whatever you use if needed). Then we will have a loop checking for the inputs. We can create it wherever we want, let’s call it appcode/. We already have the folder for GIT_DIR (the one called gitrem/), but we need another folder for our code. GIT_WORK_TREE: location to put the code when it’s received.We will use some git environment variables to run and move the code. Since it’s the same as web, if web was built and run correctly, we can safely do all at once with web2. Wait until web is ready (with a timeout).If there are no errors, start the web container.The hook is a bash script that will do the following. ![]() Docker does not play well with iptables, so I use ufw-docker to set up the firewall. I’m giving a custom name to the reverse proxy image. web2 only exposes it to the internal docker-compose network. The only difference is that web exposes the port both to the internal docker-compose network and to localhost (that will be important later). Web and web2 are the same container, but with different names. There are 2 important things to notice here. dockerfile: Dockerfile ports: - "8000" volumes: caddy_data: caddy_config: dockerfile: Dockerfile ports: # expose port to localhost too - "8000:8000" web2: build: context. dockerfile: Dockerfile.caddy # giving it a name to use with ufw-docker container_name: caddy_cont_1 ports: - "80:80" - "443:443" volumes: - caddy_data:/data - caddy_config:/config web: build: context. Version: "3.8" services: caddy: build: context. This is the docker-compose.yaml (with some details omitted): The 2 copies have different names so that we can keep one alive if our deployment is not successful. Instead of replicating the docker-compose service, we will treat them as 2 different services with different names, they just run the same code. Then we will be running 2 copies of our web backend. We have one load balancer/reverse proxy, I’ll be using Caddy here. Our Docker imagesīefore going through our git hook, let me explain how the architecture looks. Some notes about the post-receive hook: It can’t stop the code from being pushed, and you’ll stay connected to the remote server while it’s executing. That hook will run after new code is pushed to the remote. Server-side hooks run on the computer “receiving” the action (our remote server). Client-side hooks run on the computer doing the action (your local computer). There are client-side hooks and server-side hooks. To execute something after a git action we can use git hooks. Production :/root/gitrem (push)Įxecuting something when we push new code
0 Comments
Leave a Reply. |