标签: aws-fargate

我按照以下步骤使用连接到EC2容器实例,https: //docs.aws.amazon.com/AmazonECS/latest/developerguide/instance-connect.html想知道如何连接到FARGATE管理的容器实例.

我正在尝试使用他们的 ECS 服务在 AWS 上启动/运行 Dockerfile。我可以在本地运行我的 docker 镜像就好了，但是它在 Fargate 启动类型上失败了。我已将 Docker 映像上传到 ECR，并从中创建了一个集群/服务/任务。

但是，我的集群的任务状态只是读取“DEPROVISIONING（任务无法启动）”，但它没有提供我的运行映像输出的日志或详细信息，所以我不知道出了什么问题。如何查找更多信息并诊断为什么 ECS 无法运行我的映像？

我有一个带有服务的 Docker 容器，我想通过 Fargate 通过 AWS ECS 运行该服务。不幸的是，我要运行的服务需要访问需要将 IP 列入白名单的合作伙伴的 SFTP 服务器。

我现在的问题是：如何将静态 IP (IPv4) 分配给 AWS ECS Fargate 任务？我已经设置了 VPC、子网、互联网和 NAT 网关并将它们分配给彼此。但我看到的最大问题是，每次使用 Fargate 执行任务时，都会分配一个具有不同 IP 的新 ENI。

能得到一些帮助会很棒！:)

我已将初始 docker 映像推送到存储库并使用该映像创建了 AWS Fargate，是否有任何方法可以更新映像，因为我的 docker 映像中有某些更改。

编辑:我的第一个问题是"如何使用Fargate链接AWS ECS上的任务定义中的容器？" 但是,从一开始我可能是错的,所以我改变了我的问题,并保留以下内容:

我正在尝试通过ECS在AWS上部署一个简单的基于Laravel的应用程序.我的服务在本地使用docker-compose-yml文件按预期工作.

但在AWS上我得到:"nginx: [emerg] host not found in upstream "app" in /etc/nginx/conf.d/default.conf:12"来自我的网络容器日志.

这里是我服务的容器:web(nginx),app(Laravel),数据库(MySQL)和缓存(redis).

我知道任务描述的所有容器共享相同的命名空间,因此不需要链接容器(我们不能使用链接属性与Fargate).

你能帮我解决一下这个问题吗？我瞎了.

这是我工作的本地docker-compose.yml文件:

version: '2'
services:

  #  The Application
  app:
    image: 696759765437.dkr.ecr.us-east-1.amazonaws.com/ali-
maison/tribe-migrate
    volumes:
      - /var/www/storage
    env_file: '.env'
    environment:
      - "DB_HOST=database"
      - "REDIS_HOST=cache"

  # The Web Server
  web:
    image: 696759765437.dkr.ecr.us-east-1.amazonaws.com/ali-maison/laravel-web
    ports:
      - 80:80

  # The Database
  database:
    image: mysql:5.6
    volumes:
      - dbdata:/var/lib/mysql
    environment:
      - "MYSQL_DATABASE=homestead"
      - "MYSQL_USER=homestead"
      - "MYSQL_PASSWORD=secret"
      - "MYSQL_ROOT_PASSWORD=secret"

  # redis
  cache:
    image: redis:3.0-alpine

volumes:
  dbdata:

这是我的web容器Dockerfile:

FROM nginx:1.10

ADD vhost.conf …

我有这个任务定义代码，它有一个问题：

{
  "family": "ikg-api",
  "taskRoleArn": "",
  "executionRoleArn": "arn:aws:iam::913xxxx371:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "ikg-api",
      "image": "913xxxx371.dkr.ecr.us-west-2.amazonaws.com/ikg_api:fda0b49f8",
      "cpu": 512,
      "memory": 1024,
      "memoryReservation": 1024,
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80,
          "protocol": "tcp"
        }
      ],
      "essential": true,
      "environment": [
        {
          "name": "is_docker",
          "value": "yes"
        }
      ],
      "secrets": [
        {
          "name": "bitbucket_password",
          "valueFrom": "arn:aws:ssm:us-west-1:913xxxx0371:parameter/bitbucket_pwd"
        }
      ],
      "startTimeout": 10,
      "stopTimeout": 19,
      "user": "root",
      "workingDirectory": "/apps",
      "disableNetworking": false,
      "privileged": false,
      "readonlyRootFilesystem": false,
      "interactive": false,
      "pseudoTerminal": false,
      "healthCheck": {
        "command": [
          "curl",
          "localhost"
        ],
        "interval": …

我知道一些潜在的解决方案，但它们都让我感觉很糟糕。

1. 在管道（github操作）中，在fargate上运行一次性任务以在部署之前迁移数据库。
2. 发布某种 cloudformation 事件作为部署挂钩并将其用作 lambda 触发器，然后 lambda 将执行迁移。
3. 利用 laravel crons 和 onOneServer() 来持续检查是否需要迁移
4. [问题，不好] docker 入口点命令在任务启动时运行数据库迁移。（不好，所有实例可能都会尝试快速连续迁移数据库）

每一个都有我不喜欢的东西。

1. 这个将迁移数据库，然后部署。如果部署失败，数据库现在已迁移，为了修复它，我必须在失败后以某种方式在管道中运行数据库迁移回滚。而且，一般来说，依赖管道中的一次性任务感觉非常糟糕。
2. 这个移动部件比我认为必要的要多。多点故障：cloudformation 事件、lambda 函数故障。此外，部署似乎是事件触发器，这意味着部署可能成功，但 lambda 数据库迁移失败，并且管道不知道。因此需要手动回滚部署。
3. 这个感觉很老套，然而，似乎有最少数量的移动部件和最少的熵。然而，主要的缺点是，我认为这本质上需要 1/分钟的 cron 垃圾邮件php artisan migrate（没有任何可迁移的内容），以便它可以通过迁移捕获部署。好处是，使用 onOneServer()，它实际上应该解决这个问题：我们不希望多个实例都尝试在部署上迁移数据库，而只希望一个实例。这有一个很大的好处，就是将部署和迁移链接起来，所以如果部署失败，还没有迁移，如果迁移失败，至少可以更容易地将任务回滚到旧的任务版本。涉及的移动部件较少。每分钟发送垃圾邮件的资源开销php artisan migrate并且没有任何可回滚的内容，应该非常小/不明显的资源使用。但是，它在资源方面的效率低下仍然让我非常困扰。

还有其他解决方案吗？我预计有人可能会建议我使用环境变量控制实例，但我也不想这样做。如果我们部署并运行 3 个实例，它们都应该更新并且它们都是“相同”的实例状态。否则，我必须创建第二个服务，该服务也 24/7 运行以检查迁移作为其自己的特殊工作。我猜这是解决方案5：

5. 与 24/7 运行的请求处理实例有一个单独的服务任务，其唯一的工作是运行 cron 并在部署后迁移数据库。但这也很糟糕，因为您有一个 24/7 运行的任务来检查部署，而部署并不那么频繁。

我认为解决方案 3 是我的首选解决方案，尽管它有资源开销。我很想听听其他人对这个问题的一些见解。我所处的情况是，如果我被公共汽车撞到，这条管道对于非操作人员来说确实应该很容易处理。在 Laravel 应用程序代码中保持简单似乎符合这一要求。我知道有计划任务/云信息事件解决方案，但请记住我有一个大目标as little entropy / moving parts as possible, within reason。

我已经阅读了关于这个主题的每一篇博客文章和每一篇谷歌点击，但还没有找到明确的答案。我自己提出了解决方案 3，但没有看到任何地方建议它。

在所有情况下都可能实现自动化数据库迁移太过雄心勃勃，应该开发并遵循手动流程。特别是如果数据库迁移包含不适用于旧实例的更改 - 在部署之前迁移它会暂时破坏这些更改。

我有两个容器，它们暴露同一个端口。我想在相同的任务中运行它们，因为它们是同一系统的一部分。但是我无法使用 Fargate 执行此操作，因为没有端口映射，并且主机端口应与 awsvpc 网络模式的容器端口相同（仅 Fargate 支持）。

这是 Docker 的一个基本特性，奇怪的是 Fargate 似乎不支持它。真的没有办法做到这一点还是我错过了什么？

我正在使用 Fargate 在 ECS 中开始一项任务，在处于 PENDING 状态一段时间后，它最终处于 STOPPED 状态，并出现以下错误：

STOPPED (CannotPullContainerError: "Error response from daem

当我展开细节时，我看到

STOPPED (CannotPullContainerError: "Error response from daemon: Get https://id.dkr.ecr.ap-southeast-2.amazonaws.com/v2/: net/http: request canceled while waiting for connection"

与原因

(Client.Timeout exceeded while awaiting headers)

因此，由于某种原因，该任务无法访问容器，但我不确定缺少什么权限以及来自什么资源。我已经阅读了一些，我发现的唯一真正的建议是将 AssignPublicIp: ENABLED 添加到 AwsvpcConfiguration 但这没有帮助。

用这个稍微扯掉我的头发......我正在尝试在公共子网的 VPC 中的 Fargate 上运行 Docker 映像。当我将此作为任务运行时，我得到：

ResourceInitializationError: unable to pull secrets or registry auth: pull
command failed: : signal: killed

如果我通过 NAT 在私有子网中运行任务，它就可以工作。如果我在默认 VPC 的公共子网中运行它，它也可以工作。

我已经检查了这里的建议：

Aws ecs fargate ResourceInitializationError：无法提取机密或注册表身份验证

特别是，我设置了安全组以允许所有流量。还设置了网络 ACL 以允许所有流量。我什至对 IAM 权限非常开放，以尝试消除这种可能性：

任务执行角色有：

   {
        "Action": [
            "kms:*",
            "secretsmanager:*",
            "ssm:*",
            "s3:*",
            "ecr:*",
            "ecs:*",
            "ec2:*"
        ],
        "Resource": "*",
        "Effect": "Allow"
    }

具有信任关系，允许 ecs-tasks 承担此角色：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs-tasks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

安全组是：

sg-093e79ca793d923ab All traffic All traffic …