Re:Launch HN: Nullstone (YC W22) – An easier way to deploy a...
by krishadi on Tuesday September 05, 2023 @01:25PM
(#37394986)
AWS Copilot has been great for deploying `services`. But I wasn't sure if the `jobs` were what I was looking for, since they are event triggered. I'll test it our now.
Essentially I'd like to build a docker image of code from a repository, and deploy and run it, and manage its lifecycle. Perhaps I could copy the CF template from the Copilot to do the same.
Re:Launch HN: Nullstone (YC W22) – An easier way to deploy a...
by CharlieDigital on Tuesday September 05, 2023 @01:45PM
(#37395248)
> Essentially I'd like to build a docker image of code from a repository, and deploy and run it
Presumably, you're running it based on some input. Jobs are the right paradigm if this input is periodic (for example, processing a batch of items in S3 every few hours).
Otherwise, you may want to consider a Worker: https://aws.github.io/copilot-cli/docs/concepts/services/#wo... which can be connected to an SQS queue and activated by publishing messages to the queue.
Lifecycle management is a matter of using the delete commands:
svc delete
job delete
env delete
app delete
https://aws.github.io/copilot-cli/docs/commands/app-delete/
Hope that helps!
This is by far the best way to deploy compute into AWS in containerized workloads.
The abstraction you want is Jobs: https://aws.github.io/copilot-cli/docs/concepts/jobs/
Building this any other way on AWS would require provisioning multiple artifacts. The Copilot Jobs abstraction basically encapsulates the provisioning of those artifacts into one repeatable pattern.
Fully extensible with CDK and CF if the out-of-the-box workload abstractions aren't enough or you need deeper customization. I have found that the OOB abstractions are "right-sized" for most common workloads and rarely require extension aside from occasionally IAM when integrating with other AWS services.