Azure / azure-saas

The Azure SaaS Development Kit (ASDK) provides a reference architecture, deployable reference implementation and tools to help developers, startups, ISVs and Enterprises deliver their applications as a SaaS service. A platform for platform creators.
https://aka.ms/azuresaasdevkit
326 stars 239 forks source link

Unable to succesfully complete run.sh for SaaS Administration Service API #223

Closed alvaradojl closed 1 year ago

alvaradojl commented 1 year ago

Following the instructions of the Identitity Framework, I was able to complete a successful deployment.

Running ./setup.sh from src/Saas.Identity/Saas.Permissions/deployment completes succesfully.

But when attempting to ./run.sh from the previous folder, I get an error:

### SaaS Administration Service API ###
Provisioning the SaaS Administration Service API...
/asdk/src/Saas.Identity/Saas.Permissions/deployment/start.sh: line 42: /asdk/src/Saas.Lib/Deployment.Script.Modules/deploy-app-service.sh: Permission denied
1iveowl commented 1 year ago

Thank you @alvaradojl for reporting this.

Did you run the setup.sh script first before running run.sh? If so, what was the output?

alvaradojl commented 1 year ago

@1liveowl yes and it ran succesfully, just like with the Identity Framework setup.

Setting up the deployment environment. Settings execute permissions on necessary scripts files. Building the deployment container. [+] Building 1.5s (10/10) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 38B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/ubuntu:22.04 1.4s => [1/6] FROM docker.io/library/ubuntu:22.04@sha256:dfd64a3b4296d8c9b62aa3309984f8620b98d87e47492599ee20739e8eb5 0.0s => CACHED [2/6] RUN apt-get update && apt-get install -y curl dnsutils python3-pip jq sudo 0.0s => CACHED [3/6] RUN curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/s 0.0s => CACHED [4/6] RUN pip3 install ruamel.yaml 0.0s => CACHED [5/6] WORKDIR /asdk 0.0s => CACHED [6/6] RUN git config --global --add safe.directory /asdk 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:44d32ef004a9f78e69e2dd50f01364f0e65132e9345f544816ba47657c8bcd32 0.0s => => naming to docker.io/library/asdk-script-deployment:latest 0.0s Setting up log folder...

Setup complete. You can now run the deployment script using the command './run.sh'.

alvaradojl commented 1 year ago

Not sure if useful, but I'm running from a WSL terminal (Ubuntu 22.04): AZ CLI 2.48.1 GH CLI 2.29.0 Running from the latest version of main branch.

1iveowl commented 1 year ago

And you forked the repo first, right? You have to run it as a fork to your own repo and then clone it from your own fork.

alvaradojl commented 1 year ago

yes, I'm running from my own forked repo

1iveowl commented 1 year ago

Not sure if useful, but I'm running from a WSL terminal (Ubuntu 22.04): AZ CLI 2.48.1 GH CLI 2.29.0 Running from the latest version of main branch.

This looks correct

1iveowl commented 1 year ago

I'm assuming that your are running WSL 2.0.

The issue is related to this line of bash code:

"${SHARED_MODULE_DIR}/map-output-parameters-for-app-service.py" \
    "${APP_NAME}" \
    "${BICEP_IDENTITY_FOUNDATION_OUTPUT_FILE}" \
    "${BICEP_APP_SERVICE_DEPLOY_PARAMETERS_FILE}" \
    "${CONFIG_FILE}" | ...

You'll find the variables referenced there in the file <your github base folder>/azure-saas/src/Saas.Lib/Deployment.Script.Modules/app-service-constants.sh.

My best guess is that the script running inside the container is denied permission to one of the paths defined by these variables. Why I'm not sure.

Does this ring any bells?

alvaradojl commented 1 year ago

It does, have you managed to reproduce it?

1iveowl commented 1 year ago

It does, have you managed to reproduce it?

No. Unfortunately not. I will have to dig deeper to understand why you are seeing this and we're not.

Could you try an put a # right after bash in the last line of the run.sh script? This will open a prompt in the container w/o running the script. From this prompt could you try and access the paths?

alvaradojl commented 1 year ago

this is what i get when i run only the bash as entry point and then navigating to

/asdk/src/Saas.Identity/Saas.Permissions/deployment

and running start.sh

root@57db6e21e66d:/asdk/src/Saas.Identity/Saas.Permissions/deployment# ./start.sh
fatal: not a git repository (or any parent up to mount point /asdk/src/Saas.Identity/Saas.Permissions)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
/asdk/src/Saas.Identity/Saas.Permissions/deployment/constants.sh: line 35: /src/Saas.Lib/Deployment.Script.Modules/app-service-constants.sh: No such file or directory
./start.sh: line 15: /src/Saas.Lib/Deployment.Script.Modules/config-module.sh: No such file or directory
./start.sh: line 16: /src/Saas.Lib/Deployment.Script.Modules/log-module.sh: No such file or directory
./start.sh: line 17: /src/Saas.Lib/Deployment.Script.Modules/user-module.sh: No such file or directory
./start.sh: line 23: CONFIG_FILE: unbound variable

But files seem to be there:

root@57db6e21e66d:/asdk/src/Saas.Lib/Deployment.Script.Modules# ls -l
total 164
-rw-r--r-- 1 1000 1000  2933 May 11 08:56 act-credentials-module.sh
-rw-r--r-- 1 1000 1000 14536 May 11 08:56 app-reg-module.sh
-rw-r--r-- 1 1000 1000  1299 May 11 08:56 app-service-constants.sh
-rw-r--r-- 1 1000 1000  1828 May 11 08:56 backup-module.sh
-rw-r--r-- 1 1000 1000   599 May 11 08:56 clean-credentials.sh
-rw-r--r-- 1 1000 1000   254 May 11 08:56 colors-module.sh
-rw-r--r-- 1 1000 1000 13258 May 11 08:56 config-module.sh
-rwxr-xr-x 1 1000 1000  1960 May 11 08:56 deploy-app-service.sh
-rw-r--r-- 1 1000 1000  1997 May 11 08:56 deploy-config-entries.sh
-rw-r--r-- 1 1000 1000   637 May 11 08:56 deploy-debug.sh
-rw-r--r-- 1 1000 1000  1703 May 11 08:56 deploy-service-module.sh
-rw-r--r-- 1 1000 1000  3087 May 11 08:56 github-module.sh
-rw-r--r-- 1 1000 1000  6718 May 11 08:56 key-vault-module.sh
drwxr-xr-x 2 1000 1000  4096 May 11 08:56 linux-ubuntu
-rw-r--r-- 1 1000 1000  4327 May 11 08:56 log-module.sh
drwxr-xr-x 2 1000 1000  4096 May 11 08:56 macos
-rw-r--r-- 1 1000 1000  2297 May 11 08:56 map-output-parameters-for-app-service.py
-rw-r--r-- 1 1000 1000  1254 May 11 08:56 oidc-workflow-module.sh
-rw-r--r-- 1 1000 1000  1122 May 11 08:56 patch-github-workflow.py
-rw-r--r-- 1 1000 1000  4680 May 11 08:56 policy-module.sh
-rw-r--r-- 1 1000 1000  1478 May 11 08:56 resource-module.sh
-rw-r--r-- 1 1000 1000 11990 May 11 08:56 service-principal-module.sh
-rw-r--r-- 1 1000 1000  6607 May 11 08:56 storage-module.sh
-rw-r--r-- 1 1000 1000  5639 May 11 08:56 tenant-login-module.sh
-rw-r--r-- 1 1000 1000  4828 May 11 08:56 user-module.sh
-rw-r--r-- 1 1000 1000  7974 May 11 08:56 util-module.sh
alvaradojl commented 1 year ago

@1iveowl would it be possible that it doesn't work as expected when the github repo is private? I noticed that the run.sh copies the entire .git directory. Just a thought....

alvaradojl commented 1 year ago

When I noticed this error:

root@cf97a5da5b74:/asdk/src/Saas.Identity/Saas.Permissions/deployment# ./start.sh
fatal: not a git repository (or any parent up to mount point /asdk/src/Saas.Identity/Saas.Permissions)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Then I updated the start.sh and right before line 61 I added git init

Which then gave me an error that it could not find the bicep files:

cp: cannot stat '/asdk/src/Saas.Identity/Saas.Permissions/deployment/Bicep/Parameters/parameters-template.json': No such file or directory

I noticed that there were two folders: Bicep and bicep in the Saas.Permissions/deployment directory and the file app-service-constants.sh had the following settings:

# local bicep script directory
BICEP_DIR="${BASE_DIR}/Bicep"
BICEP_PARAMETERS_DIR="${BASE_DIR}/Bicep/Parameters"

which I changed to

BICEP_DIR="${BASE_DIR}/bicep"
BICEP_PARAMETERS_DIR="${BASE_DIR}/bicep/Parameters"

Then i noticed the error is still there because in fact there is no file in the project with the path Saas.Permissions/deployment/bicep/Parameters/app-service-parameters.json

So I guess someone forgot to check them in?

1iveowl commented 1 year ago

Thank you. This is interesting. Please allow me to investigate a bit further. I don't recall if this file is supposed to be part of the repo or something that is generated by the script.

I can't look at this today. But I will look at it tomorrow.

alvaradojl commented 1 year ago

I think I found the root problem:

docker run \
    --interactive \
    --tty \
    --rm \
    --volume "${host_deployment_dir}":"${container_deployment_dir}":ro \
...

The host_deployment_dir cannot be read-only because it's also the path for the bicep parameter file (which as you mentioned is generated dynamically).

So removing :ro did the job, as so:

docker run \
    --interactive \
    --tty \
    --rm \
    --volume "${host_deployment_dir}":"${container_deployment_dir}" \

After this change, the run.sh completed succesfully.

1iveowl commented 1 year ago

I've looked at this and there was some inconsistencies in the naming that have now been fixed: https://github.com/Azure/azure-saas/commit/4d793effb72482be4868c3dc66fd69453e54d980.

Unfortunately, I've not have had the opportunity to test it end-to-end yet, as I currently do not have access to a test environment. I will do this later.

My guess is that you've uncovered this issue/bug because you are cloning your repo to a directory within your WSL. If you clone it to a Windows directory and accessing it from WSL using /mnt/<drive-name>/path, the bug gets masked because Windows does not care about the case of a directory, whereas Linux does. In any case, it's a bug and as soon as I get a chance to test it, I will be able to verify if it has been fixed.

Btw. It is not a read-only issue, as there's a specific volume with read access to ./bicep/Parameters defined in run.sh. See:

...
--volume "${host_deployment_dir}/bicep/Parameters":"${container_deployment_dir}"/bicep/Parameters \
...
alvaradojl commented 1 year ago

many thanks @1iveowl that makes a lot of sense, I also think some sh files were checked-in without execution permissions, particularly in the Saas.Lib, so maybe the documentation should ask to run chmod +x in case they find the deployment container fails with "missing permissions". One more thing, would it make sense to also change the "Parameters" directory to lowercase?

1iveowl commented 1 year ago

I was able to recreate the issue, fix it and run a test. It should be working now. https://github.com/Azure/azure-saas/commit/9dd13516ca09c6e25c8be128118e748e81e17ee3

Also fixed the naming inconsistencies and chmod issues.

Please let me know if it works for you now too. Please be aware that you'll have to run setup.sh again before running run.sh.

Thanks for reporting this!