You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

There are many different options available to run containers on AWS, so we would like to determine the best way to run Clowder in containers on AWS.


Raw EC2 - Docker Compose on raw EC2 instances

Example: https://opensource.ncsa.illinois.edu/bitbucket/projects/CATS/repos/clowder/browse/docker-compose.yml

Pricing:


Pros:

  • No additional learning required

Cons:

  • Price of this option could prove to be higher than others

Open Questions:

  • Prices? What do we know about our expected workload?
    • We could do some CPU/memory/IO profiling on existing systems
  • Are there better options out there that could bring down price without too much additional architecture?

ECS via EC2 (kops) - Classic Kubernetes with an AWS twist

Example: https://opensource.ncsa.illinois.edu/confluence/display/~lambert8/KnowEnG+Kubernetes+Deployment#KnowEnGKubernetesDeployment-14-16:AssignaDNSrecordanddeploytheNGINXIngressLoadBalancer(ILB)

Pricing:


Pros:

  • Maximum flexibility / control over your cluster

Cons:

  • Most complex to setup (but I've done it before)

Open Questions:

  • Prices? What do we know about our expected workload?
    • We could do some CPU/memory/IO profiling on existing systems

EKS: Kubernetes with an AWS UI

Example: https://github.com/aws-samples/aws-workshop-for-kubernetes

Pricing:

  • "You pay $0.20 per hour for each Amazon EKS cluster that you create."
  • "You can use a single Amazon EKS cluster to run multiple applications by taking advantage of Kubernetes namespaces and IAM security policies."
  • "You pay for AWS resources (e.g. EC2 instances or EBS volumes) you create to run your Kubernetes worker nodes."
  • "You only pay for what you use, as you use it; there are no minimum fees and no upfront commitments."
  • See EKS Pricing: https://aws.amazon.com/eks/pricing/


Pros:

  • Less infrastructure to manage

Cons:

  • Assumption: we may have less control over what gets deployed (kube-apiserver flags, K8S versions, etc)

Open Questions:

  • Prices? What do we know about our expected workload?
    • We could do some CPU/memory/IO profiling on existing systems

ECS via FarGate - effectively docker-compose on invisible EC2?

Example: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-cli-tutorial-fargate.html

Pricing:

  • "The price per vCPU is $0.00001406 per second ($0.0506 per hour) and per GB memory is $0.00000353 per second ($0.0127 per hour)."
  • "You pay only for what you use."
  • See FarGate Pricing: https://aws.amazon.com/fargate/pricing/

NOTE: Some users say that FarGate is better suited for batch operations, and not for services that are expected to run 24/7


Pros:

  • Least effort to manage - no underlying infrastructure to worry about, and you pay based on usage
  • Easiest migration, as it appears to take a format similar to docker-compose

Cons:

  • Assumption: Least flexible - may not be able to run all types of workloads here, but we shouldn't need to run cronjobs or batch jobs or anything like that
  • Many unknowns - it's unclear what potential features we might be losing here (for example, LMA)

Open Questions:

  • Prices? What do we know about our expected workload?
    • We could do some CPU/memory/IO profiling on existing systems
  • LMA: do we need to provide monitoring/logging/alerts ourselves? Perhaps this is something that AWS FarGate provides for its containers?
  • Persistent storage: are Docker volumes safely backed by EBS, EFS, or some other persistent storage options?
  • Shared storage: do we need shared storage (e.g. NFS/EFS)? Is such a thing provided by FarGate?
  • Networking: How do the container networks work? Does it simply use the configured networks in the docker-compose.yaml as expected?
  • No labels