Why containerized?
Not all teams use the same version of the Serverless.com framework. Also, teams use different versions of Serverless packages. This can result in different versions being installed on different delegates, and requires that users select which delegate to use via delegate tags. Rather than installing and cleaning up the various Serverless versions on delegates, you can use containerized steps to spin up a fresh container with parameters like: * Serverless.com version * Serverless plugins * Jobs execution using Serverless. Once a containerized step is run, Harness terminates the container.IAMCredentials.json
```json { "Statement": [ { "Action": [ "apigateway:*", "cloudformation:CancelUpdateStack", "cloudformation:ContinueUpdateRollback", "cloudformation:CreateChangeSet", "cloudformation:CreateStack", "cloudformation:CreateUploadBucket", "cloudformation:DeleteStack", "cloudformation:DeleteChangeSet", "cloudformation:Describe*", "cloudformation:EstimateTemplateCost", "cloudformation:ExecuteChangeSet", "cloudformation:Get*", "cloudformation:List*", "cloudformation:UpdateStack", "cloudformation:UpdateTerminationProtection", "cloudformation:ValidateTemplate", "dynamodb:CreateTable", "dynamodb:DeleteTable", "dynamodb:DescribeTable", "dynamodb:DescribeTimeToLive", "dynamodb:UpdateTimeToLive", "ec2:AttachInternetGateway", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateInternetGateway", "ec2:CreateNetworkAcl", "ec2:CreateNetworkAclEntry", "ec2:CreateRouteTable", "ec2:CreateSecurityGroup", "ec2:CreateSubnet", "ec2:CreateTags", "ec2:CreateVpc", "ec2:DeleteInternetGateway", "ec2:DeleteNetworkAcl", "ec2:DeleteNetworkAclEntry", "ec2:DeleteRouteTable", "ec2:DeleteSecurityGroup", "ec2:DeleteSubnet", "ec2:DeleteVpc", "ec2:Describe*", "ec2:DetachInternetGateway", "ec2:ModifyVpcAttribute", "events:DeleteRule", "events:DescribeRule", "events:ListRuleNamesByTarget", "events:ListRules", "events:ListTargetsByRule", "events:PutRule", "events:PutTargets", "events:RemoveTargets", "iam:AttachRolePolicy", "iam:CreateRole", "iam:DeleteRole", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:GetRole", "iam:PassRole", "iam:PutRolePolicy", "iam:TagRole", "iot:CreateTopicRule", "iot:DeleteTopicRule", "iot:DisableTopicRule", "iot:EnableTopicRule", "iot:ReplaceTopicRule", "kinesis:CreateStream", "kinesis:DeleteStream", "kinesis:DescribeStream", "lambda:*", "logs:CreateLogGroup", "logs:DeleteLogGroup", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:FilterLogEvents", "logs:GetLogEvents", "logs:PutSubscriptionFilter", "s3:GetBucketLocation", "s3:CreateBucket", "s3:DeleteBucket", "s3:DeleteBucketPolicy", "s3:DeleteObject", "s3:DeleteObjectVersion", "s3:GetObject", "s3:GetObjectVersion", "s3:ListAllMyBuckets", "s3:ListBucket", "s3:PutBucketNotification", "s3:PutBucketPolicy", "s3:PutBucketTagging", "s3:PutBucketWebsite", "s3:PutEncryptionConfiguration", "s3:PutObject", "sns:CreateTopic", "sns:DeleteTopic", "sns:GetSubscriptionAttributes", "sns:GetTopicAttributes", "sns:ListSubscriptions", "sns:ListSubscriptionsByTopic", "sns:ListTopics", "sns:SetSubscriptionAttributes", "sns:SetTopicAttributes", "sns:Subscribe", "sns:Unsubscribe", "states:CreateStateMachine", "states:DeleteStateMachine" ], "Effect": "Allow", "Resource": "*" } ], "Version": "2012-10-17" } ``` The `s3:GetBucketLocation` action is required for a custom S3 bucket only.Configure delegate YAML for IRSA
To configure the delegate YAML for IRSA, do the following: 1. Create the IAM role with the policies you want the Delegate to use. The policies you select depend on what AWS resources you are deploying via the delegate. 2. In the cluster where the delegate will be installed, create a service account and attach the IAM role to it. The following example creates a new service account in the cluster where you will install the delegate and attaches the IAM policy to it: ```bash eksctl create iamserviceaccount \ --name=cdp-admin \ --namespace=harness-delegate-ng \ --cluster=test-eks \ --attach-policy-arn=For legacy delegate, add serviceAccountName to the Statefulset spec.
Example serverless.yaml file for Serverless V1
```yaml service: <+service.name> frameworkVersion: "2 || 3" provider: name: aws runtime: nodejs12.x functions: hello: handler: handler.hello events: - httpApi: path: /tello method: get package: artifact: <+artifact.path> plugins: - serverless-deployment-bucket@latest ``` The [Harness expression](https://developer.harness.io/harness-platform/use-harness-platform/variables-and-expressions/harness-variables) `<+artifact.path>` appears in `artifact: <+artifact.path>`. The expression `<+artifact.path>` tells Harness to get the artifact from **Artifacts** section of the Service. The artifact is added next. The expression `<+service.name>` uses the Harness Service name for the deployed service name. For Docker images, you use the expression `<+artifact.image>`.Example serverless.yaml file for Serverless V2
```yaml service: {{.Values.serviceName}} frameworkVersion: "2 || 3" provider: name: aws runtime: nodejs12.x functions: hello: handler: handler.hello events: - httpApi: path: /tello method: get package: artifact: {{.Values.artifact.path}} plugins: - serverless-deployment-bucket@latest ``` A corresponding `values.yaml` file that is added in the same place as the manifest resolves variables such as `{{.Values.serviceName}}`. Follow the preceding steps to add a manifest, but at step 3 select **Values YAML** instead. The following is an example of a `values.yaml` file for the manifest: ```yaml serviceName: goldenpipeline artifact: path: /my-artifact ```Install a new delegate
1. In **Delegates Setup**, select **Install new Delegate**. The delegate wizard appears. 2. In the **New Delegate** dialog, in **Select where you want to install your Delegate**, select **Kubernetes**. 3. In **Install your Delegate**, select **Kubernetes Manifest**. 4. Enter a delegate name. * Delegate names must be unique within a namespace and should be unique in your cluster. * A valid name includes only lowercase letters and does not start or end with a number. * You can use the dash character ("-") as a separator between letters. 5. At a terminal, run the following cURL command to copy the Kubernetes YAML file to the target location for installation: ```bash curl -LO https://raw.githubusercontent.com/harness/delegate-kubernetes-manifest/main/harness-delegate.yaml ``` 6. Open the `harness-delegate.yaml` file. Find and specify the following placeholder values as described: | **Value** | **Description** | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `PUT_YOUR_DELEGATE_NAME` | Name of the delegate. | | `PUT_YOUR_ACCOUNT_ID` | Harness account ID. | | `PUT_YOUR_MANAGER_ENDPOINT` | URL of your cluster. Go to the following table of Harness clusters and endpoints. | | `PUT_YOUR_DELEGATE_TOKEN` | Delegate token. To find it, go to **Account Settings** > **Account Resources**, select **Delegate**, and select **Tokens**. For more information on how to add your delegate token to the harness-delegate.yaml file, go to [Secure delegates with tokens](https://developer.harness.io/harness-platform/use-harness-platform/delegates/delegate/secure-delegates/secure-delegates-with-tokens). | Your Harness manager endpoint depends on your Harness SaaS cluster location. Use the following table to find the Harness manager endpoint in your Harness SaaS cluster. | **Harness cluster location** | **Harness Manager endpoint** | | ---------------------------- | ------------------------------- | | SaaS prod-1 |
Click to view full size image