view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

            waf:true
            waf:enabled
            waf:default

        Any of these will enable WAF and apply the `default` managed rule
        bundle, which provides a strong security baseline including
        protections against the OWASP Top 10 and SQL injection.

    - **Enable with specific rule sets:**

        You can specify a comma-separated list of rule set keywords. This
        allows you to tailor the protection to your application's specific
        needs from the very first command.

            waf:base,php,admin

    - **Enable with bundles and subtractive syntax:**

        For more complex configurations, you can use pre-configured bundles
        and the subtractive syntax (prefixing a keyword with a `-`) to remove
        unwanted rule sets.

            waf:all,-windows,-php

    When the `create-stack` command sees the `waf:` keyword, it will
    automatically generate the corresponding `waf` block in your
    `fargate-stack.yml` file, including `enabled: true` and the
    specified `managed_rules`. See ["Configuring Managed Rules"](#configuring-managed-rules) for a
    full list of available keywords and bundles.

    For more information see ["AWS WAF Support"](#aws-waf-support).

#### Output

Emits YAML to STDOUT that includes:

- `account`, `profile`, `region`
- `app.name` set from the first positional `<app-name>`
- Optional `domain` (for HTTP/HTTPS stacks)
- `tasks` map keyed by service `<name>` with fields such as `type`,
`image`, and `schedule` (when applicable)

#### Options

- **--route53-profile** _STR_

    AWS profile to use when performing Route 53 API calls. Many environments
    use a separate account for DNS management; this option lets you target
    that account. If not provided, the tool uses **--profile**.

    This option is only consulted when the command needs Route 53 (for example,
    HTTP/HTTPS stacks that require hosted zone lookups or record creation).

- **--dns-profile** _STR_

    Alias for **--route53-profile**.

- **--region** _STR_

    AWS region used when expanding ECR shorthand.

- **--out** _FILE_

    Write YAML to a file instead of STDOUT.

- **--force**

    Proceed even if some validations warn (for example, missing ECR repo).

#### Exit Status

    0 on success
    non-zero on argument or validation errors

#### NOTES

- This command generates config; it does not deploy. Run your normal "plan/apply"
flow after reviewing the YAML.
- For HTTP/HTTPS, `domain:` is required at creation time in this shorthand.
- Always quote `schedule:...` to avoid shell interpretation of parentheses.

### deploy-service

    deploy-service service-name

When you provision an HTTP, HTTPS, or daemon service, the framework
sets up all the necessary infrastructure components -- but it **does not**
automatically create and start the ECS service.

Use this command to start the service:

    app-FargateTask deploy-service service-name

If you want to start multiple tasks for the service, you can include a
count argument:

    app-FargateTask deploy-service service-name 2

### delete-daemon

    delete-daemon task-name

Deletes the AWS resources associated with a task of type
`daemon`. Consider removing the service
(["remove-service"](#remove-service)) or stopping the service
(["stop-service"](#stop-service)) if you do not want to delete the actual
resources.

See ["Notes on Deletion of Resources"](#notes-on-deletion-of-resources) for additional details.

### delete-scheduled-task

    delete-scheduled-task task-name

Deletes the AWS resources associated with a task of type `task` that
includes a `schedule:` key.

See ["Notes on Deletion of Resources"](#notes-on-deletion-of-resources) for additional details.

### delete-task

README.md  view on Meta::CPAN

The framework places each task's ENI into exactly one subnet, which fixes
that task in a single AZ. A service can span multiple AZs by listing
subnets from at least two AZs.

What the framework does:

- Prefers private subnets

    If private subnets are defined in the configuration, tasks are placed
    there. If no private subnets are defined, the framework falls back to
    public subnets.

- Aligns ALB AZs with task placement

    When a load balancer is used, the framework enables the ALB in the same
    AZ set it selects for tasks (best practice). This is for resilience and
    to avoid unnecessary cross-AZ hops; it is not a hard technical requirement.

- Requires two subnets

    The configuration must specify at least two subnets in different AZs.
    If subnets are not specified, the framework attempts to discover them,
    but still requires at least two usable subnets (either both private or
    both public). If fewer than two are available, it errors with guidance.

Notes on internet access and ALBs:

- Internet-facing ALB

    An internet-facing ALB must be created in public subnets. Tasks may (and
    usually should) remain in private subnets behind it.

- Egress from private subnets

    For image pulls and outbound calls, use either a NAT Gateway in each AZ
    or VPC endpoints for ECR (api and dkr) and S3.

- Egress from public subnets

    If tasks are placed in public subnets without endpoints or NAT, they
    require `assignPublicIp=ENABLED` to reach ECR/S3.

## REQUIRED SECTIONS

At minimum, your configuration must include the following:

    app:
      name: my-stack

    tasks:
      my-task:
        image: my-image
        type: daemon | task | http | https

For task types `http` or `https`, you must also specify a domain name:

    domain: example.com

## FULL SCHEMA OVERVIEW

The framework will expand and update your configuration file with default values as needed.
Here is the full schema outline. All keys are optional unless otherwise noted:

     ---
     account:
     alb:
       arn:
       name:
       port:
       type:
     app:
       name:             # required
       version:
     certificate_arn:
     cluster:
       arn:
       name:
     default_log_group:
     domain:              # required for http/https tasks
     id:
     last_updated:
     region:
     role:
       arn:
       name:
       policy_name:
     route53:
       profile:
       zone_id:
     security_groups:
       alb:
         group_id:
         group_name:
       fargate:
         group_id:
         group_name:
     subnets:
       private:
       public:
     tasks:
       my-task:
         arn:
         cpu:
         family:
         image:           # required
         log_group:
           arn:
           name:
           retention_days:
         memory:
         name:
         size:
         target_group_arn:
         target_group_name:
         task_definition_arn:
         type:            # required (daemon, task, http, https)
     vpc_id:

[Back to Table of Contents](#table-of-contents)

# TASK SIZE