Deploy to production

[adolski]

Now that I have an ARM-based Mac, I've been able to figure out how to build an x86 Docker image with it, since that is still what the Book Tracker is using in ECS. (I assume we'll want to switch to ARM in production eventually, but that's a separate issue.)

In order to get a deploy working, here is what you'll have to do:

1. Update your rails-container-scripts submodule (git submodule update --remote)
2. Copy the environment variable files you'll need into your rails-container-scripts directory from here: https://uofi.app.box.com/folder/221871628316
3. git pull origin develop demo to update the book tracker code (I made some other changes)
4. docker buildx create --use (only have to do this once ever, I think)

At this point your environment should be set up for deploying. To do the deploy, you would do something like:

1. aws login
2. git checkout demo
3. rails-container-scripts/redeploy.sh demo

@gaurijo I've already done the deploy to demo on my end, but please try it yourself and let me know if you run into any problems. Once you've deployed to demo then it should be easy to deploy to production.

[gaurijo]

Running that gives me the following output: (which I'm guessing is not what I want to see)

/usr/local/bin/psql: Mach-O 64-bit executable x86_64

[adolski]

I think your Homebrew has installed the x86 build of postgres. I don't know if it's installing everything for x86? If /usr/local/bin is full of stuff and /opt/homebrew/bin isn't, then that would answer it. I don't know how Homebrew works in this regard, so it may require some Googling to figure out how to reconfigure Homebrew to install ARM binaries instead.

[gaurijo]

Edited to add: When looking at contents of both /usr/local/binand /opt/homebrew/bin, both are full of a bunch of stuff, and both include postgres. I'm not sure why things were installed in both x86 and ARM

Apologies in advance for the long-winded response, this is more so to keep myself organized on what I did to get to this point.

I was not able to install rbenv 3.2.2 without some tinkering: When I was first installing it, I got a

BUILD FAILED
installing default openssl libraries
linking shared-object openssl.bundle
1 warning generated
linking shared-object ripper.bundle

When googling I found it was likely an issue with openssl, and ran brew install openssl@1.1, which gave the following output:

Error: Cannot install under Rosetta 2 in ARM default prefix (/opt/homebrew)! To rerun under ARM use:

arch -arm64 brew install ...

To install under x86_64, install Homebrew into /usr/local

Googling again showed that Homebrew installation running under Rosetta 2 on the ARM architecture can cause compatibility issues when trying to build native extensions like openssl to Ruby.

When I then switched Homebrew to run in x86_64 mode, I updated my shell profile to include the x86_64 installation in my PATH, (export PATH="/usr/local/bin:$PATH)so I believe that's why everything was installing for x86_64. In this case, ruby 3.2.2 ended up being installed, but then when running bundle, those pg errorsstarted up.

I'll keep researching possible steps I can take, but I think the root issue is the way ruby 3.2.2 was installed on my machine.

[gaurijo]

Now that deploying to demo has worked(!!!) is it essentially the same steps to deploy to production?

[adolski]

Yes, it's the same, except rails-container-scripts/redeploy.sh prod instead of demo. Also you should merge the demo branch into the production branch first and deploy that.

Finally, you can push all branches when ready.

[gaurijo]

I was trying to first update the slight modification I made to the docker-build.shfile inside the rails-container-scripts, but think something went wrong when trying to push the change up.

I had changed the docker-build.sh to specify the AWS dockerfile path when building the image:

docker buildx build --platform linux/amd64,linux/arm64 --push \
    -t $ECR_HOST/$IMAGE_NAME -f docker/book-tracker-aws/Dockerfile .

I did a cd into the rails-container-scripts submodule

Then a git status showed:

HEAD detached at d756c1b
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   docker-build.sh

no changes added to commit (use "git add" and/or "git commit -a")

So I did a git add docker-build.sh

followed by a commit: rails-container-scripts % git commit -m"Specify AWS dockerfile in build script" which gave the following output:

[detached HEAD c9e1f53] Specify AWS dockerfile in build script
 1 file changed, 1 insertion(+), 1 deletion(-)

I then cd..out of the submodule, back into book-tracker

git add rails-container-scripts git commit -m"update docker build script reference"

which gave the following:

[demo 59905ae] update docker build script reference
 1 file changed, 1 insertion(+), 1 deletion(-)

Then I ran git push

However, I see that it just added the second commit, and I never actually pushed up the first commit that made the change to the docker-build.sh

I didn't want to mess with it further at this point, since this is dealing with the demo branch. Would you be able to tell me how I can either undo whatever I pushed up and/or the best way to get the rails-container-scripts changes pushed up? Could I just cd back into the submodule and push up my changes from there?

[adolski]

rails-container-scripts is shared by several different projects. We don't want to modify it in a way that would break compatibility with them (like the -f docker/book-tracker-aws/Dockerfile would do). By default it's looking for the Dockerfile in the project root, which is a symlink to docker/book-tracker-aws/Dockerfile, which should be OK (?). Let me know if that's not the case on your end.

Submodules are separate git repositories. You have to commit/push/merge etc. them separately from the parent. To get back onto the master branch of rails-container-scripts you should be able to do something like:

cd rails-container-scripts
git checkout master
git pull

[gaurijo]

Thanks! I didn't realize the rails-container-scripts submodule was shared by several projects. I'll be careful with modifying that.

I pulled down the master branch of it, merged demo branch into production and deployed to aws prod from there (looks like it was successful):

Are you able to confirm if the production branch looks up-to-date with demo branch on your end?

Here is the confirmation on my end that demo was merged into prod branch:

[adolski]

Everything looks good to me, @gaurijo.

As a final step, I merged production back into develop and pushed it.