|
| 1 | +# Compose Setup for pgEdge Development |
| 2 | + |
| 3 | +This setup allows you to build and run a multi-node pgEdge setup using Docker Compose. Below are the instructions and available arguments to customize your setup. |
| 4 | + |
| 5 | +## Prerequisites |
| 6 | + |
| 7 | +- Docker |
| 8 | +- Docker Compose |
| 9 | + |
| 10 | +## Files |
| 11 | + |
| 12 | +- `docker-compose.yaml`: Defines the services and configurations for the Docker Compose setup. |
| 13 | +- `Makefile`: Contains the commands to manage the Docker Compose setup. |
| 14 | +- `proxy_server.py`: Contains the code which enables the repo proxy container |
| 15 | +- `Dockerfile.node.<os>`: Dockerfiles for each supported operating system |
| 16 | +- `Dockerfile.repo`: Dockerfile for the repo proxy server |
| 17 | + |
| 18 | +## Usage |
| 19 | + |
| 20 | +### Starting the Environment |
| 21 | + |
| 22 | +To start the environment, run the following command: |
| 23 | + |
| 24 | +```sh |
| 25 | +make compose-up |
| 26 | +``` |
| 27 | + |
| 28 | +This will build and start the services defined in the `docker-compose.yaml` file in Docker. |
| 29 | + |
| 30 | +### Stopping the Environment |
| 31 | + |
| 32 | +To stop the environment, run: |
| 33 | + |
| 34 | +```sh |
| 35 | +make compose-down |
| 36 | +``` |
| 37 | + |
| 38 | +### Accessing the build container |
| 39 | + |
| 40 | +The build container is where you make code changes and build packages. |
| 41 | + |
| 42 | +To access the build container, run: |
| 43 | + |
| 44 | +```sh |
| 45 | +make exec-build |
| 46 | +``` |
| 47 | + |
| 48 | +### Configuring the build container |
| 49 | + |
| 50 | +The build container is setup the same as a standard development environment outside of Docker. |
| 51 | + |
| 52 | +Required credentials (AWS, Git) are not configured on the build container. |
| 53 | + |
| 54 | +You must configure these after starting the environment, and run `50-pull-IN.sh` if needed for your work. |
| 55 | + |
| 56 | +### Understanding the repo container |
| 57 | + |
| 58 | +The repo container serves as a local http server inside the network for fetching CLI packages. |
| 59 | + |
| 60 | +It's setup as a proxy, where the default behavior is to serve a local package if it exists. |
| 61 | + |
| 62 | +If a local package does not exist, it will fallback to a package available in the chosen REPO. |
| 63 | + |
| 64 | +The chosen repo corresponds to the URL that you choose to configure: |
| 65 | + |
| 66 | +- http://repo:8000/download corresponds with https://pgedge-download.s3.amazonaws.com/REPO |
| 67 | +- http://repo:8000/upstream corresponds with https://pgedge-upstream.s3.amazonaws.com/REPO |
| 68 | +- http://repo:8000/devel corresponds with https://pgedge-devel.s3.amazonaws.com/REPO |
| 69 | + |
| 70 | +The `out` directory within the build container is mounted in the repo container to enable this setup. |
| 71 | + |
| 72 | +You can monitor the behavior of the proxy via `docker logs pgedge-repo-1` |
| 73 | + |
| 74 | +### Building the CLI packages |
| 75 | + |
| 76 | +A common workflow in this setup is to leverage already built packages to increase development velocity. |
| 77 | + |
| 78 | +If you are only working on the CLI code, you can typically just build that component: |
| 79 | + |
| 80 | +``` |
| 81 | +source env.sh |
| 82 | +./build.sh -X posix -c $bundle-cli -N $hubV |
| 83 | +``` |
| 84 | + |
| 85 | +From there, utilize the node containers to test out your changes. Other packages will be pulled from the configured REPO. |
| 86 | + |
| 87 | +### Accessing node containers |
| 88 | + |
| 89 | +node containers are used to test changes you have developed within the build container. |
| 90 | + |
| 91 | +You can access individual node containers using the following commands: |
| 92 | + |
| 93 | +```sh |
| 94 | +make exec-n1 |
| 95 | +make exec-n2 |
| 96 | +# ... up to make exec-n10 |
| 97 | +``` |
| 98 | + |
| 99 | +Once connected, you can setup the pgEdge CLI using the repo container: |
| 100 | + |
| 101 | +``` |
| 102 | +wget $REPO/install.py |
| 103 | +python3 install.py |
| 104 | +cd pgedge |
| 105 | +``` |
| 106 | + |
| 107 | +## Networking |
| 108 | + |
| 109 | +All containers in the compose setup are attached to the same docker bridge network. This makes it easier to connect across nodes using hostnames. |
| 110 | + |
| 111 | +- `repo` and `build` can be accessed directly by these hostnames since there are no replicas |
| 112 | +- nodes can be accessed via hostnames prefixed with the compose name `pgedge-node-1` |
| 113 | + |
| 114 | +## Available arguments |
| 115 | + |
| 116 | +You can customize the setup using the following arguments: |
| 117 | + |
| 118 | +- `NUM_NODES`: Number of node containers to deploy. Default is `2`. |
| 119 | +- `OS_ARCH`: The OS architecture for the node containers. Default is `linux/$(uname -m)`. |
| 120 | +- `OS_FLAVOR`: The OS flavor for the node containers. Supported values are `rocky95` and `ubuntu2204`. Default is `rocky95`. |
| 121 | +- `BUILD_OS_FLAVOR`: The OS architecture for the build container. Default is `linux/$(uname -m)`. |
| 122 | +- `BUILD_OS_ARCH`: The OS flavor for the build container. Supported values are `rocky95` and `rocky810`. Default is `rocky95`. |
| 123 | +- `REPO`: The repository URL for downloading dependencies. Default is `http://repo:8000/download`. |
| 124 | + |
| 125 | +### Example |
| 126 | + |
| 127 | +To start the environment with 3 nodes and using `ubuntu2204` as the OS flavo, with the REPO set to upstream, run: |
| 128 | + |
| 129 | +```sh |
| 130 | +REPO=http://repo:8000/upstream NUM_NODES=3 OS_FLAVOR=ubuntu2204 make compose-up |
| 131 | +``` |
| 132 | + |
| 133 | +## Notes |
| 134 | + |
| 135 | +- Passwordless SSH is setup between the nodes to make it easier to test the cluster module |
| 136 | +- The `PGBACKREST_REPO1_CIPHER_PASS` environment variable is set to `supersecret` by default. Change it as needed. |
0 commit comments