3 ms·

I am looking for a service that helps me orchestrate the deployments of docker containers in AWS. These containers run Python workloads, but are not web-api end

I am looking for a service that helps me orchestrate the deployments of docker containers in AWS. These containers run Python workloads, but are not web-api endpoints. I want to be able to deploy them programmatically and, pause them if they've been idle (something like what supabase does). Is this something you are looking to provide? From a quick glance at your docs, it seems that you are mainly focussing on web facing applications.

CharlieDigital 3y ago
Check out AWS Copilot CLI: https://aws.github.io/copilot-cli/ https://aws.github.io/copilot-cli/ 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/ 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.
- krishadi 3y ago
  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.
  - CharlieDigital 3y ago
    > 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/#worker-service 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 To de-provision. https://aws.github.io/copilot-cli/docs/commands/app-delete/ https://aws.github.io/copilot-cli/docs/commands/app-delete/ Hope that helps!
    - krishadi 3y ago
      Thanks a ton!
ssickles99 3y ago
Nullstone does support this use case, all applications are private by default. In order to make them public, you would add a Load Balancer, CDN, or Api Gateway. In your case, just don't add this and your application will remain private. We don't currently support the automatic pause of applications due to inactivity. However, we do support starting/stopping your app via the UI, API, or CLI.
- krishadi 3y ago
  Cool, could you point me a link to the API for deploying, starting, stopping the app?
  - ssickles99 3y ago
    We don't have our API documented yet but here is the documentation for the CLI. https://docs.nullstone.io/getting-started/cli/docs.html https://docs.nullstone.io/getting-started/cli/docs.html To launch your application you would use the `nullstone up` command. To tear it down you would use the `nullstone down` command. To deploy your code, you would use the `nullstone launch`. Each of these command are just making API calls under the hood. If you want to hop on our Slack channel, I'd be glad to share the details.
bsick7 3y ago
This is something we support as well. You're correct that most of our documentation (including quickstarts) focuses primarily on web-facing apps. Our current modules support running Python jobs using Fargate/ECS and Lambda (using Docker containers or packaged zip files). Today, it is possible to pause workloads by destroying the app (nullstone down --app=<app>). Obviously, that's not ideal and we do have plans to support pausing workloads to reduce costs.
- krishadi 3y ago
  Gotcha, do you also provide functions to build and store docker images from a code repo?
  - ssickles99 3y ago
    We support auto build/deploy upon the launch of your application and then on every code commit to the branch configured. The docker image is stored in a container registry in your cloud account. Outside of the auto build/deploy process, we don't yet support ad-hoc docker builds.

CharlieDigital 3y ago

Check out AWS Copilot CLI: https://aws.github.io/copilot-cli/ https://aws.github.io/copilot-cli/ 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/ 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.

krishadi 3y ago
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.
- CharlieDigital 3y ago
  > 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/#worker-service 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 To de-provision. https://aws.github.io/copilot-cli/docs/commands/app-delete/ https://aws.github.io/copilot-cli/docs/commands/app-delete/ Hope that helps!
  - krishadi 3y ago
    Thanks a ton!

ssickles99 3y ago

Nullstone does support this use case, all applications are private by default. In order to make them public, you would add a Load Balancer, CDN, or Api Gateway. In your case, just don't add this and your application will remain private. We don't currently support the automatic pause of applications due to inactivity. However, we do support starting/stopping your app via the UI, API, or CLI.

krishadi 3y ago
Cool, could you point me a link to the API for deploying, starting, stopping the app?
- ssickles99 3y ago
  We don't have our API documented yet but here is the documentation for the CLI. https://docs.nullstone.io/getting-started/cli/docs.html https://docs.nullstone.io/getting-started/cli/docs.html To launch your application you would use the `nullstone up` command. To tear it down you would use the `nullstone down` command. To deploy your code, you would use the `nullstone launch`. Each of these command are just making API calls under the hood. If you want to hop on our Slack channel, I'd be glad to share the details.

bsick7 3y ago

This is something we support as well. You're correct that most of our documentation (including quickstarts) focuses primarily on web-facing apps. Our current modules support running Python jobs using Fargate/ECS and Lambda (using Docker containers or packaged zip files). Today, it is possible to pause workloads by destroying the app (nullstone down --app=<app>). Obviously, that's not ideal and we do have plans to support pausing workloads to reduce costs.

krishadi 3y ago
Gotcha, do you also provide functions to build and store docker images from a code repo?
- ssickles99 3y ago
  We support auto build/deploy upon the launch of your application and then on every code commit to the branch configured. The docker image is stored in a container registry in your cloud account. Outside of the auto build/deploy process, we don't yet support ad-hoc docker builds.