6/29/2023 0 Comments Pgbouncer docker![]() ![]() Added the postgres service with all the configurations we need to spin up a local Postgres server.This creates a dependency between the api service and the postgres service (useful as the NestJS service will need to access the Postgres database). Add a depends_on section to the api service.Here's the edits that have been made to the docker-compose.yml file: other Redis container configs postgres : image : postgresĮnvironment : POSTGRES_DB : $ ports : - '5432:5432' volumes : - docker -nest -postgres :/var/lib/postgresql/data other Nest container configs depends_on : - redis Add docker-compose fileĪdd a docker-compose.yml file to your project: See the # BUILD FOR LOCAL DEVELOPMENT stage in the Dockerfile above? That's what we'll isolate and target in the docker-compose.yml file. The great thing about multistage builds is that you can target a specific stage in your docker-compose file and run a specific command against the stage. dist # Start the server using the production build CMD node_modules COPY -chown = node:node -from = build /usr/src/app/dist. RUN npm ci -only=production & npm cache clean -force USER node # PRODUCTION # FROM node:18-alpine As production # Copy the bundled code from the build stage to the production image COPY -chown = node:node -from = build /usr/src/app/node_modules. # This ensures that the node_modules directory is as optimized as possible. # Passing in -only=production ensures that only the production dependencies are installed. # Run the build command which creates the production bundle RUN npm run build # Set NODE_ENV environment variable ENV NODE_ENV production # Running `npm ci` removes the existing node_modules directory. COPY -chown = node:node -from = development /usr/src/app/node_modules. # So we can copy over the node_modules directory from the development image into this build image. # The Nest CLI is a dev dependency, # In the previous development stage we ran `npm ci` which installed all dependencies. # In order to run `npm run build` we need access to the Nest CLI. # Use the node user from the image (instead of the root user) USER node # BUILD FOR PRODUCTION # FROM node:18-alpine As build WORKDIR /usr/src/app COPY -chown = node:node package*.json. ![]() # Install app dependencies using the `npm ci` command instead of `npm install` RUN npm ci # Bundle app source COPY -chown = node:node. # Copying this first prevents re-running npm install on every code change. # A wildcard is used to ensure copying both package.json AND package-lock.json (when available). $ docker exec -it myclient psql -h 172.17.0.# BUILD FOR LOCAL DEVELOPMENT # FROM node:18-alpine As development # Create app directory WORKDIR /usr/src/app # Copy application dependency manifests to the container image. $ docker exec -it mybouncer sed -i "s/0.0.0/0.0.3/" /etc/pgbouncer/bouncer_hba.conf $ docker exec -it mybouncer sed -i "s/17.0.0/0.0.0/" /etc/pgbouncer/bouncer_hba.conf $ docker exec -it mybouncer sed -i "s/16/8/" /etc/pgbouncer/bouncer_hba.conf $ docker exec -it mybouncer service pgbouncer restart $ docker exec -it mybouncer sed -i "s/0.4/0.0/" /etc/pgbouncer/bouncer_hba.conf $ docker exec -it myclient psql -h 172.17.0.4 -p6432 -c "select 1" prodb enterprisedb $ docker exec -it mybouncer cat /etc/pgbouncer/bouncer_hba.conf ![]() Now, if you want to use the server's IP address, the CIDR parsing behaves a bit unexpectedly in order for bouncer_hba.conf to work as expected, the CIDR notation requires zeros for the masked/irrelevant portions (note that myclient has IP address 172.17.0.5, but as you'll see, it's not really relevant in the examples I show below): $ docker exec -it mydb cat /var/lib/edb/as9.6/data/pg_hba.conf Psql: ERROR: login pgbouncer]# psql -h 172.17.0.4 -p6432 -c "select 1" prodb enterprisedb But if you use the server's IP address (and not the loopback address), it'll work: pgbouncer]# cat bouncer_hba.conf For example, using 127.0.0.1 won't work unless the HBA file is set to 0.0.0.0/0. However, there are a few gotchas that make it a little tricky for new users, and I hope that clarify one of those with this post. Since then, several improvements have been implemented, including the ability to use auth_type=hba, which implements a PG-like HBA authentication method similar to the pg_hba.conf format we're all used to. I've been using it for many years, since it first became available in 2007. PgBouncer is a great tool for improving database performance with connection pooling. ![]()
0 Comments
Leave a Reply. |