Boundary on EKS

Hi

I’m trying to setup Boundary on EKS. So far I’ve been following the reference architecture for kubernetes. Having gotten to the point of deploying the init container runs the database init command but hangs. I’m using a fresh RDS instance of Postgres 12 and I’ve tried running database migrate which works so I don’t think it’s an issue with connection. Running top inside of the container shows the init command running, any ideas? I’m also using the latest release 0.1.7 for reference.

Thanks

So oddly after about 5 minutes it then ran and migrated the db, I’ve not set any resource requests/limits on the pods as per the reference architecture but is it known to be this slow to initialise the first time?

I’m also attempting to get Boundary deployed in EKS and writing a Helm Chart to manage it. Testing locally I’m just using Docker Desktop with k8s engine enabled. I’ve split the controller and worker pod deployments to eventually allow both to be independently auto-scaled. The controller pod deployment includes an initContainer that executes the database init or migration.

I’ve monitored the logs and see that the init container runs the init/migrate command and I’ve logged into the PostgreSQL database and confirmed it’s gone from a fresh empty database to having multiple tables created and many have records. So I’m not exactly seeing the same issue you are reporting.

The issue I’m seeing is when I go to the controller endpoint :9200 I’m being told there are no auth methods available. I’ve confirmed this via the browser and Boundary Desktop. Both the controller and worker pods are running, I currently have set replicas: 1 just to limit scope during development testing.

I’m executing with the hashicorp/boundary:0.8.1 image and keeping it simple using AEAD for KMS though I have prepared for using Vault Transit or AWS KMS. While I intend to run against a PostgreSQL RDS instance when in AWS, on Docker Desktop I’m using the 14.3 PostgreSQL image.

Are there auth methods in an org scope? If not, what options did you pass to boundary database init?

I actually found it was because I had mistakenly added the -skip-* options to the initial call to boundary database init. I deleted the Helm deployment, dropped and re-created the database and redeployed after removing the options and it it create the password auth method for the global scope so I could log into the UI.

I also removed the database migrate/init from being an initContainer and instead made it a Job with pre-* Helm hooks to execute it before the ReplicaSet Deployments as it only needs to execute once as the boundary server execution pods will not allow the boundary database [migrate|init] process to have exclusive use of the database and locks everything up failing.