view release on metacpan or  search on metacpan

share/README.md  view on Meta::CPAN

task definition. This is the primary command for deploying any changes
to your application, including new container images, environment
variables, or resource allocations.

When an ECS service is launched, it is "pinned" to a specific revision
of a task definition (e.g., my-task:9). If you later push a new
container image or change the task's configuration in your
configuration file, the running service **will not** automatically pick up
those changes.

This command is the essential final step in the deployment process.

- If the service is running, this command will trigger a rolling
deployment to replace the existing tasks with new ones based on the
new task definition.
- If the service is stopped, this command updates its
configuration. The next time you run start-service, it will launch
tasks using the new task definition.

**When to use `update-service` vs. `redeploy`**

While both commands can result in a new deployment, they serve
different purposes:

Use `update-service` when you have made any change to your
configuration file that affect the task definition. This is the
correct command for deploying a new image, adding environment
variables, injecting secrets, changing CPU/memory, or adding EFS mount
points. The workflow is:

Update your configuration file.

Run `app-FargateStack register-task-definition task-name`

Run `app-FargateStack update-service task-name`

Use `redeploy` as a shortcut only when you have pushed a new image using
the same tag (e.g., :latest) and have made no other configuration
changes. redeploy forces a new deployment using the existing task
definition, which is simpler but will not apply any other updates.

The status command can help you detect drift by showing if the running
task definition is out of sync with your latest configuration.

### update-target

    update-target task-name

Updates an EventBridge rule and rule target. For tasks of type "task"
(typically scheduled jobs) when you change the schedule the rule must
be deleted, re-created and associated with the target task. This
command will detect the drift in your configuration and apply the
changes if not in `--dryrun` mode.

### version              

Outputs the current version of `App::FargateStack`.

## Notes on Deletion of Resources

- You will be prompted to confirm the operation before any task is
deleted.
- If the specified task is the only one defined in your configuration
file, its configuration will not be fully removed. Instead, the task's
provisioned resource ARNs and names will be deleted, leaving behind a
minimal configuration skeleton. This allows you to re-provision the
task later by running `plan` against the skeleton, avoiding the need
to recreate it from scratch.
- `App::FargateStack` does not delete ECR images associated with tasks.
- ACM certificates provisioned by `App::FargateStack` will not be
deleted.

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

# DEPLOYMENT WORKFLOW GUIDE

One of the most common questions when managing a stack is, "I changed
X, what command(s) do I need to run now?" This guide provides a
quick-reference matrix to help you choose the correct workflow for the
most common changes.

## How to Use This Matrix

Find the change you made in the "Change Description" column and follow
the row across to see which commands are required. Commands should be
run in order from left to right.

    +---------------------------------------------+---------+---------+----------+----------+
    | Change Description                          | apply   | register| update-  | redeploy |
    |                                             |         | -task   | service  |          |
    +---------------------------------------------+---------+---------+----------+----------+
    | Updated container image (new tag/digest)    |         |    X    |    X     |          |
    |---------------------------------------------+---------+---------+----------+----------|
    | Updated container image (same :latest tag)  |         |         |          |    X     |
    |---------------------------------------------+---------+---------+----------+----------|
    | Added/changed environment variables         |         |    X    |    X     |          |
    |---------------------------------------------+---------+---------+----------+----------|
    | Added/changed secrets                       |    X    |    X    |    X     |          |
    |---------------------------------------------+---------+---------+----------+----------|
    | Added/changed CPU, memory, or size          |         |    X    |    X     |          |
    |---------------------------------------------+---------+---------+----------+----------|
    | Changed a scheduled task's cron/rate        |    X    |         |          |          |
    |---------------------------------------------+---------+---------+----------+----------|
    | Added a new S3 bucket or SQS queue          |    X    |    X    |    X     |          |
    |---------------------------------------------+---------+---------+----------+----------|
    | Added or changed an EFS mount point         |    X    |    X    |    X     |          |
    +---------------------------------------------+---------+---------+----------+----------+

## Notes on the Workflow

- `plan` is Your Best Friend: Before running apply or any command that
makes changes, it is always a good practice to run app-FargateStack
plan first. This will give you a dry-run preview of the changes and
help you catch any configuration errors.
- Why apply is Sometimes Needed: Changes that affect AWS
resources beyond the ECS task definition itself -- like IAM
permissions for a new secret, EventBridge rules for a new schedule, or
provisioning a new S3 bucket -- require running apply to create or
update that infrastructure.
- redeploy is a Shortcut: The redeploy command is a special
case. It's a convenient shortcut for the common scenario where you've