Hand-off of Docker/act from U-CS Team

[galenatjpl]

@pymonger to get from @buggtb

[buggtb]

@pymonger current builds are here https://github.com/unity-sds/unity-cs-infra/pkgs/container/unity-cs-infra

https://github.com/unity-sds/unity-cs-infra#running-unity-workflows-outside-of-github basic commands to run the container here

for now you need to shell inside and invoke act(installed in /home/ubuntu/bin) inside the unity-cs folder

https://github.com/unity-sds/unity-cs-infra/blob/main/Dockerfile feel free to make changes to the docker image it rough and ready to make stuff work.

[pymonger]

Thanks @buggtb. I'm assuming we're running the deploy_eks_oidc.yml workflow. Running from an management/deployer EC2 instance in the Unity DEV account, I had to make this mod to get past a command not found error:

diff --git a/.github/workflows/deploy_eks_oidc.yml b/.github/workflows/deploy_eks_oidc.yml
index 70985b2..794225a 100644
--- a/.github/workflows/deploy_eks_oidc.yml
+++ b/.github/workflows/deploy_eks_oidc.yml
@@ -72,6 +72,11 @@ jobs:

     # Steps represent a sequence of tasks that will be executed as part of the job
     steps:
+      - name: Install AWS CLI
+        run: |
+          apt update -y && \
+          DEBIAN_FRONTEND=noninteractive apt install awscli -y
+
       # Configure AWS Credentials through OIDC
       - name: Configure AWS credentials
         if: ${{ secrets.OIDC_ROLE  != '' }}

Despite that, the workflow fails at the eksctl run:

[MCP Dev - EKS Deployment via OIDC/deployment] ⭐ Run Main Launch EKS cluster
[MCP Dev - EKS Deployment via OIDC/deployment]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/8] user= workdir=
| 2022-12-20 16:00:15 [ℹ]  eksctl version 0.123.0
| 2022-12-20 16:00:15 [ℹ]  using region us-west-2
| 2022-12-20 16:00:15 [✔]  using existing VPC (vpc-0106218dbddd3a753) and subnets (private:map[us-west-2a:{subnet-087b54673c7549e2d us-west-2c 10.0.64.0/19 0 } us-west-2b:{subnet-009c32904a8bf3b92 us-west-2d 10.0.96.0/19 0 }] public:map[])
| 2022-12-20 16:00:15 [!]  custom VPC/subnets will be used; if resulting cluster doesn't function as expected, make sure to review the configuration of VPC/subnets
| 2022-12-20 16:00:15 [ℹ]  nodegroup "dafaultgroupNodeGroup" will use "ami-01fe93a8bc6cb9bef" [AmazonLinux2/1.21]
| 2022-12-20 16:00:15 [ℹ]  using Kubernetes version 1.21
| 2022-12-20 16:00:15 [ℹ]  creating EKS cluster "--owner" in "us-west-2" region with managed nodes
| 2022-12-20 16:00:15 [ℹ]  1 nodegroup (dafaultgroupNodeGroup) was included (based on the include/exclude rules)
| 2022-12-20 16:00:15 [ℹ]  will create a CloudFormation stack for cluster itself and 0 nodegroup stack(s)
| 2022-12-20 16:00:15 [ℹ]  will create a CloudFormation stack for cluster itself and 1 managed nodegroup stack(s)
| 2022-12-20 16:00:15 [ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=us-west-2 --cluster=--owner'
| 2022-12-20 16:00:15 [ℹ]  Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "--owner" in "us-west-2"
| 2022-12-20 16:00:15 [ℹ]  CloudWatch logging will not be enabled for cluster "--owner" in "us-west-2"
| 2022-12-20 16:00:15 [ℹ]  you can enable it with 'eksctl utils update-cluster-logging --enable-types={SPECIFY-YOUR-LOG-TYPES-HERE (e.g.all)} --region=us-west-2 --cluster=--owner'
| 2022-12-20 16:00:15 [ℹ]
| 2 sequential tasks: { create cluster control plane "--owner",
|     2 sequential sub-tasks: {
|         2 sequential sub-tasks: {
|             wait for control plane to become ready,
|             1 task: { create addons },
|         },
|         create managed nodegroup "dafaultgroupNodeGroup",
|     }
| }
| 2022-12-20 16:00:15 [ℹ]  building cluster stack "eksctl---owner-cluster"
| 2022-12-20 16:00:16 [!]  1 error(s) occurred and cluster hasn't been created properly, you may wish to check CloudFormation console
| 2022-12-20 16:00:16 [ℹ]  to cleanup resources, run 'eksctl delete cluster --region=us-west-2 --name=--owner'
| 2022-12-20 16:00:16 [✖]  creating CloudFormation stack "eksctl---owner-cluster": operation error CloudFormation: CreateStack, https response error StatusCode: 400, RequestID: 32b5d93c-b5a3-4187-960b-4d9d6829e245, api error ValidationError: 1 validation error detected: Value '' at 'tags.5.member.value' failed to satisfy constraint: Member must have length greater than or equal to 1
| Error: failed to create cluster "--owner"
[MCP Dev - EKS Deployment via OIDC/deployment]   ❌  Failure - Main Launch EKS cluster
[MCP Dev - EKS Deployment via OIDC/deployment] exitcode '1': failure
[MCP Dev - EKS Deployment via OIDC/deployment] 🏁  Job failed
Error: Job 'deployment' failed

Does the rendered eksctl-config.yaml have to be tweaked somehow? If you have an example of one that successfully deploys and EKS cluster I can try to incorporate them back into a PR.

[buggtb]

I'm not sure which one I ran @pymonger probably the deploy_eks.yml workflow not the oidc one as we don't have any OIDC connection to leverage.

The actual error you're seeing if due to there no being any inputs passed in via a config file. I can't show you cause HQ have locked me out and I need to call them but you basically need an act input file with CLUSTERNAME defined as a minimum so it can pass it in which its not doing and is why you see that error. https://github.com/nektos/act#pass-inputs-to-manually-triggered-workflows

You should also ping @jonathansmolenski who's looking to integrate all the AWS permissions and stuff into an IAM role and ensure the integrated workflows run, so you dont' duplicate effort.

[pymonger]

@buggtb : i'll give that a try. I already have a proof-of-concept CloudFormation template that successfully deploys an EC2 instance with the proper instance role which then deploys an EKS cluster manually via eksctl and then deploys SPS on top of it using terraform. The next iteration of it will replace my manual call to eksctl with your act stuff. @jonathansmolenski: Here's the roles needed by the EC2 instance to sucessfully deploy EKS and SPS: https://github.com/unity-sds/unity-on-demand-cloudformation/blob/develop/templates/unity_deployer_instance.yaml#L83-L92. Hope that helps.

[galenatjpl]

@pymonger and @buggtb : do these roles: ManagedPolicyArns:

• arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
• arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
• arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
• arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser come out of the box with Amazon (on standard amazon accounts)?

[pymonger]

@galenatjpl: yes. those are AWS-managed policies. BTW, here's the cloudformation template that uses act to deploy EKS and SPS: https://github.com/unity-sds/unity-on-demand-cloudformation/blob/develop/templates/unity_deployer_instance-act.yaml. It runs successfully in my MAAP-HEC MCP account (non-Unity). Will need to see if it works in our Unity DEV account which has a different variant of the tenantOperator policy, mcp-tenantOperator-AMI-APIG.