App-FargateStack

 view release on metacpan or  search on metacpan

lib/App/FargateStack/Pod.pm  view on Meta::CPAN

unwanted rule sets.

  waf:all,-windows,-php

=back

When the C<create-stack> command sees the C<waf:> keyword, it will
automatically generate the corresponding C<waf> block in your
F<fargate-stack.yml> file, including C<enabled: true> and the
specified C<managed_rules>. See L</Configuring Managed Rules> for a
full list of available keywords and bundles.

For more information see L</AWS WAF Support>.

=back

=head4 Output

Emits YAML to STDOUT that includes:

=over 4

=item *

C<account>, C<profile>, C<region>

=item *

C<app.name> set from the first positional C<< <app-name> >>

=item *

Optional C<domain> (for HTTP/HTTPS stacks)

=item *

C<tasks> map keyed by service C<< <name> >> with fields such as C<type>,
C<image>, and C<schedule> (when applicable)

=back

=head4 Options

=over 4

=item B<--route53-profile> I<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 B<--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).

=item B<--dns-profile> I<STR>

Alias for B<--route53-profile>.

=item B<--region> I<STR>

AWS region used when expanding ECR shorthand.

=item B<--out> I<FILE>

Write YAML to a file instead of STDOUT.

=item B<--force>

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

=back

=head4 Exit Status

  0 on success
  non-zero on argument or validation errors

=head4 NOTES

=over 4

=item *

This command generates config; it does not deploy. Run your normal "plan/apply"
flow after reviewing the YAML.

=item *

For HTTP/HTTPS, C<domain:> is required at creation time in this shorthand.

=item *

Always quote C<schedule:...> to avoid shell interpretation of parentheses.

=back

=head3 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 B<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

=head3 delete-daemon

 delete-daemon task-name

Deletes the AWS resources associated with a task of type
C<daemon>. Consider removing the service
(L</remove-service>) or stopping the service
(L</stop-service>) if you do not want to delete the actual

lib/App/FargateStack/Pod.pm  view on Meta::CPAN

=item * 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.

=item * 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.

=item * 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.

=back

Notes on internet access and ALBs:

=over 4

=item * Internet-facing ALB

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

=item * 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.

=item * Egress from public subnets

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

=back

=head2 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 C<http> or C<https>, you must also specify a domain name:

  domain: example.com

=head2 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:

=head1 TASK SIZE

To simplify task configuration, the framework supports a shorthand key called



( run in 0.955 second using v1.01-cache-2.11-cpan-5b529ec07f3 )