Issue while runing ./bin/deploy from the RAils on Lambda in 5min guide

[richardsondx]

The instruction are not working on a M1 machine:

qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

Note: we also the docker run command is successful after we run it; we also get the following warning when running that command:

docker run \
  --rm \
  --interactive \
  --volume "${PWD}:/var/task" \
  ghcr.io/customink/lamby-cookiecutter \
  "gh:customink/lamby-cookiecutter"
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

---

Are there any instruction on how to install Rails with Lambda in 5min in an existing project? Or even a generator?

[metaskills]

I just pushed what I think is a multi-arch image, test now? https://github.com/customink/lamby-cookiecutter/commit/1ce070fd29035c343ae08480d14cdf6855ae9745

[metaskills]

OK, few errors, some Inkers here helped me test M1 and it worked for us. Closing this out but let me know if it does not work for you. Make sure to clear your local Docker image just in case you do not automatically get the latest.

[metaskills]

Are there any instruction on how to install Rails with Lambda in 5min in an existing project? Or even a generator?

Yes and no. We cover this in the guides here https://lamby.custominktech.com/docs/anatomy No generators because this stuff changes and is outside of the Rails and can be implemented widely differently depending on a user/org's needs.

[richardsondx]

The issue seem to be happening in the SAM build step

echo "== SAM build =="
sam build \
  --parameter-overrides \
    RailsEnv="${RAILS_ENV}"

Error:

== SAM build ==
qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

[metaskills]

Is that from your Mac or a deploy pipeline in GitHub Actions?

[richardsondx]

From the deploy pipeline on Github Actions I believe since I Open it in a container and my VS code terminal is now pointing to vscode ➜ /workspaces/ and the header says [Dev Container @ desktop-linux]

So far I've tried each of the following suggested fix: 1) Adding --platform=linux/amd64 to the FROM line of Dockerfile ( source: https://stackoverflow.com/questions/71040681/qemu-x86-64-could-not-open-lib64-ld-linux-x86-64-so-2-no-such-file-or-direc) 2) Setting up ENV ARCHITECTURE=x64 in the Dockerfile 3) Setting up ENV DOCKER_DEFAULT_PLATFORM=linux/amd64

None of them worked.

Also for context:

• I setup lamby in an existing project. Adde the gem. I copied the bin/deploy file. I Copied the .devcontainer folder from a project I created following your recommende steps. Then I updated my Dockerfile to match it and made sure that all the app mention were referencing my app. The deployment seem to work until the SAM Build step.

[metaskills]

From the deploy pipeline on Github Actions I believe...

If you open in a container you are not on GitHub Actions. Using GitHub Actions would solve your issue. I'll have to get some M1 Mac testing done later. To solve your issue outlined here. https://github.com/customink/lamby/issues/143

BTW, thank you for those steps and things you tried. That will be helpful.

[richardsondx]

Oh sorry It was the AWS SAM CLI instruction from the guide that I use. I'll try Github Action today and share the results. Thanks!

[richardsondx]

I had to update deploy.yml to match the one of the sample project as well for the workflow of Github Action.

I can confirm that with Github Action I'm not getting that particular qemu error. ✅

Instead the app get stucked on a separate error when it precompile the assets.

 [2023-01-12T18:58:22.112Z] rails aborted!
  Sprockets::Rails::Helper::AssetNotFound: The asset "application.css" is not present in the asset pipeline.

which is probably application specific. I'm still investigating the cause. I'm using application.scss in my app and this is happening when the bin/deploy script is running Asset Hosts & Precompiling at this cmd:

NODE_ENV='production' ./bin/rails assets:precompile

The final error and exit code are:

   Error: Dev container exec: Command failed: bash -c ./bin/deploy (exit code: undefined)
  An error occurred running a command in the container.
  Error: Command failed: bash -c ./bin/deploy

[richardsondx]

I fix all the sprocket error by adding this to my manifest.js

//= link application.css
//= link application.js

I've noticed that I often get this error if the instance already exist on AWS. It looks like the script doesn't delete & create it automatically.

[2023-01-12T22:28:29.020Z] Error: Failed to create/update the stack: myapp-production, Waiter StackUpdateComplete failed: Waiter encountered a terminal failure state: For expression "Stacks[].StackStatus" we matched expected path: "UPDATE_ROLLBACK_COMPLETE" at least once

Usually to fix this I have to log in manually onto AWS and delete the stack in Cloud Formation.

[metaskills]

Error: Failed to create/update the stack: myapp-productio

You should not have to delete, it is not right or a scalable solution. When you click the Events tab for the stack in CloudFromation console, what was the event that caused the rollback? If you address that then deploy again it should be resolved.

[richardsondx]

Yes.. It never worked unless I delete it manually. The even is UPDATE_ROLLBACK_COMPLETE. When I delete and rerun it successfully create the stack on Cloud Formation but in Github Action it fails on the Post Action

Post job cleanup.
Pushing image ''ghcr.io/customink/myappdevcontainer:latest...
...
....
 denied: permission_denied: The requested installation does not exist.
  Error: Error: push failed with 1

[metaskills]

Make sure your deploy users has perms to push to ECR. https://lamby.custominktech.com/docs/anatomy#deployment--cicd

[richardsondx]

Thanks. I remember going through these IAM instructions and still ran into some permission issues. It's all set up now I had to add some permission that wasn't listed. In this context its because it was pointing to the wrong dev container I think – because I copied that dev container from another application.

Unfortunately, my client has decided to move away from this approach because of all the issues we ran into during the setup. Since I won't be able to follow up with suggestions; I will close this issue for now. Thanks for helping with these blockers.