Closed rwx-yxu closed 2 years ago
Getting issues with the migration directory when deploying to openfaas/faasd. It cannot find the directory. Has something to do with the dockerfile I suspect.
I am a bit confused. The dockerfile copies the contents of goinventory-api to the work dir /go/src/handler/. Adding a RUN ls line in the dockerfile shows that the migration directory has been copied over but that pathing doesn't exist when deployed.
Ah, okay. I think I get it now. go build outputs the contents to /handler/handler. This wouldn't include the migrations folder. I'll need to use go embed feature to add in that directory so it can be used when it is built. https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/
Simpler solution is to move the migrations folder in the docker image to /home/app. Using go embed isn't the correct way to go for this use case. This is because the go migrate lib will only accept a string for the migration location. Go embed requires a comment string to reference to location but also an assignment into a embed.FS variable which I will not be using. It doesn't look like the FS struct has a directory name either that I can use to easily concat for the migration location.
Since I already have the migrations folder copied over in the docker image, I can just move the directory to the one that openfaas uses to pick up the container image in /home/app
No idea why, but I am getting this 2022/04/04 23:38:38 no change exit status 1 For the migrations. I reverted the changes to what is was before where the migrations were working but it is throwing this.
I have a resolution in place. I needed to change the dockerfile to target multi arch builds to arm. I thought I had this but I needed to tweek it a little
I need to double check with the migrations first. The migration for the test table is failing.
Resolved. There was a stray comma in the test migration file.
Currently, the migration as part of the deployment workflow action pulls down the go-migrate cli and runs the migrate command before the deployment to faasd. In order for this to work, I need to have a public endpoint to my postgres instance. I can do this with inlets pro but I think it will be more simpler if I had the migrations happen on startup in the application after the database connection is made.
The benefits of this would be: