Grafana 7.4.3 /var/lib/grafana не может быть записана в AWS ECS — EFS

#grafana #amazon-ecs #amazon-efs

Вопрос:

Я пытаюсь разместить изображение Grafana 7.4 в ECS Fargate, используя том EFS для постоянного хранения.

Используя Terraform, я создал необходимый ресурс и предоставил задаче доступ к тому EFS через «точку доступа».

 resource "aws_efs_access_point" "default" {
    file_system_id = aws_efs_file_system.default.id

    posix_user {
        gid = 0
        uid = 472
    }

    root_directory {
        path = "/opt/data"

        creation_info {
            owner_gid = 0
            owner_uid = 472
            permissions = "600"
        }
    }
}
 

Обратите внимание, что я установил разрешения владельца в соответствии с руководствами в https://grafana.com/docs/grafana/latest/installation/docker/#migrate-from-previous-docker-containers-versions (Я попробовал как идентификатор группы 0, так и 1, поскольку документация, похоже, не соответствует gid).

Используя базовое изображение alpine вместо изображения grafana, я подтвердил, что каталог /var/lib/grafana существует в контейнере с правильным набором идентификаторов uid и gid. Однако при попытке запустить изображение grafana я получаю сообщение об ошибке

 GF_PATHS_DATA='/var/lib/grafana' is not writable.
 

Я запускаю задачу с терраформированным определением задачи.

 resource "aws_ecs_task_definition" "default" {
    family = "${var.name}"
    container_definitions = "${data.template_file.container_definition.rendered}"
    memory = "${var.memory}"
    cpu = "${var.cpu}"
    requires_compatibilities = [
        "FARGATE"
    ]
    network_mode = "awsvpc"
    execution_role_arn = "arn:aws:iam::REDACTED_ID:role/ecsTaskExecutionRole"

    volume {
        name = "${var.name}-volume"

        efs_volume_configuration {
            file_system_id = aws_efs_file_system.default.id
            transit_encryption = "ENABLED"
            root_directory = "/opt/data"

            authorization_config {
                access_point_id = aws_efs_access_point.default.id
            }
        }
    }

    tags = {
        Product = "${var.name}"
    }
}
 

С определением контейнера

 [
    {
        "portMappings": [
            {
                "hostPort": 80,
                "protocol": "tcp",
                "containerPort": 80
            }
        ],
        "mountPoints": [
            {
                "sourceVolume": "${volume_name}",
                "containerPath": "/var/lib/grafana",
                "readOnly": false
            }
        ],
        "cpu": 0,
        "secrets": [
            ...
        ],
        "environment": [],
        "image": "grafana/grafana:7.4.3",
        "name": "${name}",
        "user": "472:0"
    }
]
 

Для «пользователя» я попробовал «графана», «742:0», «742» и «742:1» при попытке gid 1.

Я считаю, что терраформа, группы безопасности, mount_targets и т. Д…. Все правильно, так как я могу получить альпийское изображение на:

 ls -lash /var/lib
> drw------- 2 472 root 6.0K Mar 12 11:22 grafana
 

Ответ №1:

Я считаю, что у вас есть проблема, потому что AWS ECS https://github.com/aws/containers-roadmap/issues/938

В любом случае, подход к файловой системе, по-видимому, не очень удобен для облачных вычислений (особенно если вы хотите масштабироваться горизонтально: проблемы с одновременной записью из нескольких задач, ограничения ввода-вывода …). Просто предоставьте правильную базу данных (например, Aurora RDS Mysql, кластер multi A-Z, если вам нужен HA), и у вас будет хорошее развертывание AWS без операций.

Комментарии:

1. Спасибо, я верю, что вы правы в этом. Я не знал, что grafana просто запускает sqlite, его документы не всегда так ясны. Нам не нужна высокая доступность или масштабирование, но в любом случае Aurora RDS в любом случае казалась более чистым решением.