U
туда ходи
Size: a a a
2020 July 13
MI
почему в амазоне не дает удалить s3 бакет если я зашел под рутовой учеткой
Может стоять защита от удаления, которую надо сначала отключить
VS
почему в амазоне не дает удалить s3 бакет если я зашел под рутовой учеткой
бакет пустой? или с чем то корзинка
AS
бакет пустой? или с чем то корзинка
уже пустой
AS
нашел, надо было going into the bucket and deleting the "Bucket Policy" for the bucket.
ДС
Коллеги, подскажите пожалуйста, как лучше всего выдавать права на директорию хоста контейнеру в docker?
Например, у меня есть контейнер с prometheus и нужно чтобы он писал данные в /etc/prometheus/data. Сейчас я при запуске контейнера указываю volumes: - /opt/prometheus/data:/etc/prometheus/data, а на саму папку выставляю права sudo chown 65534:65534 -R (drwxr-xr-x 17 nobody nogroup ). Но не уверен что это правильно.
Например, у меня есть контейнер с prometheus и нужно чтобы он писал данные в /etc/prometheus/data. Сейчас я при запуске контейнера указываю volumes: - /opt/prometheus/data:/etc/prometheus/data, а на саму папку выставляю права sudo chown 65534:65534 -R (drwxr-xr-x 17 nobody nogroup ). Но не уверен что это правильно.
I
Дмитрий Стародубцев
Коллеги, подскажите пожалуйста, как лучше всего выдавать права на директорию хоста контейнеру в docker?
Например, у меня есть контейнер с prometheus и нужно чтобы он писал данные в /etc/prometheus/data. Сейчас я при запуске контейнера указываю volumes: - /opt/prometheus/data:/etc/prometheus/data, а на саму папку выставляю права sudo chown 65534:65534 -R (drwxr-xr-x 17 nobody nogroup ). Но не уверен что это правильно.
Например, у меня есть контейнер с prometheus и нужно чтобы он писал данные в /etc/prometheus/data. Сейчас я при запуске контейнера указываю volumes: - /opt/prometheus/data:/etc/prometheus/data, а на саму папку выставляю права sudo chown 65534:65534 -R (drwxr-xr-x 17 nobody nogroup ). Но не уверен что это правильно.
@docker_ru @ru_docker
но обычно хватает прав того пользователя под которым запускаешь контейнеры.
Также есть нюанс, что внутри контейнера id пользователя должен совпадать с id овнера.
например, где на хостой машине user(id=1000) а в контейнере у пользователя jenkins(id=1000)
И простой пример -
но обычно хватает прав того пользователя под которым запускаешь контейнеры.
Также есть нюанс, что внутри контейнера id пользователя должен совпадать с id овнера.
например, где на хостой машине user(id=1000) а в контейнере у пользователя jenkins(id=1000)
И простой пример -
chown -R user.root /opt/prometheusДС
@docker_ru @ru_docker
но обычно хватает прав того пользователя под которым запускаешь контейнеры.
Также есть нюанс, что внутри контейнера id пользователя должен совпадать с id овнера.
например, где на хостой машине user(id=1000) а в контейнере у пользователя jenkins(id=1000)
И простой пример -
но обычно хватает прав того пользователя под которым запускаешь контейнеры.
Также есть нюанс, что внутри контейнера id пользователя должен совпадать с id овнера.
например, где на хостой машине user(id=1000) а в контейнере у пользователя jenkins(id=1000)
И простой пример -
chown -R user.root /opt/prometheusСпасибо!
I
MM
Рубрика: вопросы за 50.
Зачем выбирать, где терминировать SSL (backend, elb, etc.), если можно его вообще там не терминировать, а сделать это на клаудфлере?
Зачем выбирать, где терминировать SSL (backend, elb, etc.), если можно его вообще там не терминировать, а сделать это на клаудфлере?
C
а если у тебя нет cloudflare?
C
ну и это доп. защита между сервисами
MM
Не, это понятно. У нас вот есть и оно у нас ВЕЗДЕ затерминировано, даже на приложении. И ты меняешь серты везде, каждый раз. Вопрос больше про то, что есть ли в этом профит...
C
если все сервисы внутри одного облака, скажем авс тот же, то наверное особо смысла нет, всё крутится внутри себя
а если это разные облака или дц, то опять та же защита дополнительная
а вот чтобы не страдать каждый раз обновлением сертов, для этого и существуют девопсы, чтобы автоматизировали и забыли)))
а если это разные облака или дц, то опять та же защита дополнительная
а вот чтобы не страдать каждый раз обновлением сертов, для этого и существуют девопсы, чтобы автоматизировали и забыли)))
MM
если все сервисы внутри одного облака, скажем авс тот же, то наверное особо смысла нет, всё крутится внутри себя
а если это разные облака или дц, то опять та же защита дополнительная
а вот чтобы не страдать каждый раз обновлением сертов, для этого и существуют девопсы, чтобы автоматизировали и забыли)))
а если это разные облака или дц, то опять та же защита дополнительная
а вот чтобы не страдать каждый раз обновлением сертов, для этого и существуют девопсы, чтобы автоматизировали и забыли)))
Ага, просто был бы один провайдер в тераформе вместо трех) особенно когда все внутри одного облака, где ты единственный админ.
C
щито поделать
NB
Рубрика: вопросы за 50.
Зачем выбирать, где терминировать SSL (backend, elb, etc.), если можно его вообще там не терминировать, а сделать это на клаудфлере?
Зачем выбирать, где терминировать SSL (backend, elb, etc.), если можно его вообще там не терминировать, а сделать это на клаудфлере?
трафик от cloudflare до инфраструктуры явно пойдет по публичным каналам же?
MM
Nikita Burtsev
трафик от cloudflare до инфраструктуры явно пойдет по публичным каналам же?
Да, должен быть серт на сервере, это в настройках СF называется Full (strict)
MM
И чтобы ее поставить, нужно
Configure your origin web server to allow HTTPS connections on port 443 and present either a Cloudflare Origin CA certificate or a valid certificate purchased from a Certificate Authority.
NB
э. я понимаю слова "терминировать ssl" как переход на нешифрованное взаимодействие. а вы тут явно что-то другое понимаете под этим