всем привет, подскажите пожалуйста, это нормально давать контейнеру доступ выполнять команды на хосте? с большими ограничениями разумеется. или мне девопс потом все мозги выеет мол это несекьюрненько

полагаю вы правы)

правы в чем простите? то есть можно?

> или мне девопс потом все мозги выеет мол это несекьюрненько

хотя

опишите кейс

мб это будет оправдано

всем привет, подскажите пожалуйста, это нормально давать контейнеру доступ выполнять команды на хосте? с большими ограничениями разумеется. или мне девопс потом все мозги выеет мол это несекьюрненько

В такой неопределенной формулировке... Если этого можно избежать, этого стоит избежать:)

идея в том что нужно запускать автотесты в контейнере, потому что на разных осях они по-разному работают. запускать через docker-compose. проблема в том что этот контейнер с тестами должен иметь возможность контролировать окружение, то есть убить базу например, чтобы проверить что хелсчек не 200 ОК постоянно шлет в независимости от того работает база или нет например) поэтому и хочется этому контейнеру дать управление. по сути мой киллер аргумент это то что это не продакшн юзадж, а ci/cd только

я в курсе за изоляцию контейнеров, и это все очень хорошо, но по-другому не вижу как

А как вообще предполагается команды на хосте запускать?

почему вы не хотите убить базу которая в контейнере?)

А как вообще предполагается команды на хосте запускать?

честно говоря пока не смотрел как, судя по стаковерфлоу как-то так ssh -l ${USERNAME} ${HOSTNAME} "${SCRIPT}"

почему вы не хотите убить базу которая в контейнере?)

то есть запросом убить? не сам контейнер положить?

жутко выглядит

честно говоря пока не смотрел как, судя по стаковерфлоу как-то так ssh -l ${USERNAME} ${HOSTNAME} "${SCRIPT}"

ахуеть...

))

то есть запросом убить? не сам контейнер положить?

можете сделать запрос который отрубит процесс базы

подскажите что не так с композом ? не создает базу данных(((

influxdb: container_name: influx image: influxdb:latest restart: always environment: - INFLUXDB_DB="samle" - INFLUXDB_ADMIN_ENABLED="true" - INFLUXDB_ADMIN_USER="admin" - INFLUXDB_ADMIN_PASSWORD="admin" - INFLUXDB_USER="user" - INFLUXDB_USER_PASSWORD="user" ports: - 8086:8086 - 8083:8083

можете сделать запрос который отрубит процесс базы

проблема в том что база это частный случай, там много сторонних приложений используется, на все конечно можно написать, но это дольше чем просто контейнер рубануть

ахуеть...

ахуеть какое говнище я так полагаю?)

подскажите что не так с композом ? не создает базу данных(((

в логах что?

идея в том что нужно запускать автотесты в контейнере, потому что на разных осях они по-разному работают. запускать через docker-compose. проблема в том что этот контейнер с тестами должен иметь возможность контролировать окружение, то есть убить базу например, чтобы проверить что хелсчек не 200 ОК постоянно шлет в независимости от того работает база или нет например) поэтому и хочется этому контейнеру дать управление. по сути мой киллер аргумент это то что это не продакшн юзадж, а ci/cd только

этим должен заниматься оркестратор, на худой конец тот же docker-compose.

этим должен заниматься оркестратор, на худой конец тот же docker-compose.

Да, но нужно как то оркестратору дать понять что пришло время убить процесс

Да, но нужно как то оркестратору дать понять что пришло время убить процесс

я могу не доконца понимать, но прописать kubectl delete pod —name=podname(не уверен насчет синтаксиса) чтобы дропнуть под с бд подойдет?

я могу не доконца понимать, но прописать kubectl delete pod —name=podname(не уверен насчет синтаксиса) чтобы дропнуть под с бд подойдет?

Написать не проблема, вопрос в том насколько это плохо давать возможность контейнеру/поду делать это

это можно делать и из ci

с удивлением обнаружил что в FROM можно подставлять переменные из ARG

но при этом делать типа COPY --from=composer:${composer_version} /usr/bin/composer /usr/local/bin/composer - нельзя

FROM php:${php_version}-fpm-stretch as php-installer COPY --from=composer:1.8.5 /usr/bin/composer /usr/local/bin/composerFROM - валидный, а COPY фейлится

а пишут что должно работать :/

ARG composer_version FROM composer:${composer_version} as composer FROM php:${php_version}-fpm-stretch as php-installer COPY --from=composer /usr/bin/composer /usr/local/bin/composerхм, а вот так работает :/

Да, но нужно как то оркестратору дать понять что пришло время убить процесс

Google: liveness probe

ARG composer_version FROM composer:${composer_version} as composer FROM php:${php_version}-fpm-stretch as php-installer COPY --from=composer /usr/bin/composer /usr/local/bin/composerхм, а вот так работает :/

Кстати, ARG видны только в пределах одного образа :)

Вопросы про докер есть?

Вопросы про докер есть?

Да

Задавай)

Задавай)

А можно мне вопрос?)

Ранее остался без ответа.

Дебиан 9.докер последний. Оверкоммит=1 и свопинесс=0 но докер контейнеры жрут своп при свободной 50% ОЗУ

Кстати, ARG видны только в пределах одного образа :)

Практика показала что нет

идея в том что нужно запускать автотесты в контейнере, потому что на разных осях они по-разному работают. запускать через docker-compose. проблема в том что этот контейнер с тестами должен иметь возможность контролировать окружение, то есть убить базу например, чтобы проверить что хелсчек не 200 ОК постоянно шлет в независимости от того работает база или нет например) поэтому и хочется этому контейнеру дать управление. по сути мой киллер аргумент это то что это не продакшн юзадж, а ci/cd только

Докер в докере можно

influxdb: container_name: influx image: influxdb:latest restart: always environment: - INFLUXDB_DB="samle" - INFLUXDB_ADMIN_ENABLED="true" - INFLUXDB_ADMIN_USER="admin" - INFLUXDB_ADMIN_PASSWORD="admin" - INFLUXDB_USER="user" - INFLUXDB_USER_PASSWORD="user" ports: - 8086:8086 - 8083:8083

Инфлакс кривой

У меня эльпайн их не создавал бд. На базе их убунты образ - все ок. При этом их же эльпайн, если подмонтировать базу уже существующую - отлично

Помогите разобраться с моим композом

Что ты делаешь, человече. Грузи на пейстбин

Что ты делаешь, человече. Грузи на пейстбин

Я в докере не в зуб ногой, объясните как лучше все это сделать ??

pastebin есть такой сайт. Компоуз грузи туда

У меня эльпайн их не создавал бд. На базе их убунты образ - все ок. При этом их же эльпайн, если подмонтировать базу уже существующую - отлично

эльпин же, ударение на первый слог, безударные слоги не подчиняются правилам открытых слогов

pastebin есть такой сайт. Компоуз грузи туда

https://pastebin.com/eTvCrk17

эльпин же, ударение на первый слог, безударные слоги не подчиняются правилам открытых слогов

Ты фигню сказал

Пруф

принимается

Ненавижу инглиш ? ?

https://pastebin.com/eTvCrk17

Выкинь INFLUXDB_DB="homeassist"

Мне кажется, что эта опция годится, если база уже есть. В теории можешь запустить инфлакс ВООБЩЕ БЕЗ ВСЕХ ПЕРЕМЕННЫХ. Он должен создать БД по умолчанию. Ну, и смотри логи контейнера. Если он не может создать, что он явно напишет

volumes:  influxdb:    external: true

И почему так сделано? External:true лишнее, кмк

без всего тоже не создает

Быть того не может. Логи дай

возможно как-то пушить в кастомный репозиторий и скипать образы из официальных источников? у меня не такой быстрый интернет-канал, а пуш что-то подвис)

если твой репозиторий умеет пуллить с публичных, то сделай это, а потом пуш свой

возможно как-то пушить в кастомный репозиторий и скипать образы из официальных источников? у меня не такой быстрый интернет-канал, а пуш что-то подвис)

Вообще отключить доступ к докерхабу - не?

Практика показала что нет

Show me

Дебиан 9.докер последний. Оверкоммит=1 и свопинесс=0 но докер контейнеры жрут своп при свободной 50% ОЗУ

Swarm?

Нет, просто докер

Так пробовал? https://docs.docker.com/config/containers/resource_constraints/#--memory-swap-details

Так пробовал? https://docs.docker.com/config/containers/resource_constraints/#--memory-swap-details

? благодарю попробую

Вообще отключить доступ к докерхабу - не?

а как это поможет?)

если твой репозиторий умеет пуллить с публичных, то сделай это, а потом пуш свой

это registry v2. в него возможно запуллить перед пушем туда?

что-то типа такого нужно сделать для каждого образа? docker tag codemazeblog/accountownerapp:latest my-registry:50000/codemazeblog/accountownerapp:latest docker push my-registry:50000/codemazeblog/accountownerapp

On Thursday, April 25th, 2019, we discovered unauthorized access to a single Hub database storing a subset of non-financial user data. Upon discovery, we acted quickly to intervene and secure the site. We want to update you on what we've learned from our ongoing investigation, including which Hub accounts are impacted, and what actions users should take. Here is what we’ve learned: During a brief period of unauthorized access to a Docker Hub database, sensitive data from approximately 190,000 accounts may have been exposed (less than 5% of Hub users). Data includes usernames and hashed passwords for a small percentage of these users, as well as Github and Bitbucket tokens for Docker autobuilds. Actions to Take: We are asking users to change their password on Docker Hub and any other accounts that shared this password. For users with autobuilds that may have been impacted, we have revoked GitHub tokens and access keys, and ask that you reconnect to your repositories and check security logs to see if any unexpected actions have taken place. You may view security actions on your GitHub or BitBucket accounts to see if any unexpected access has occurred over the past 24 hours -see https://help.github.com/en/articles/reviewing-your-security-log and https://bitbucket.org/blog/new-audit-logs-give-you-the-who-what-when-and-where This may affect your ongoing builds from our Automated build service. You may need to unlink and then relink your Github and Bitbucket source provider as described in https://docs.docker.com/docker-hub/builds/link-source/ We are enhancing our overall security processes and reviewing our policies. Additional monitoring tools are now in place. Our investigation is still ongoing, and we will share more information as it becomes available. Thank you, Kent

https://m.habr.com/ru/post/449742/

Нудное без просматриваемой структуры чтиво. Осталось ощущение, что просто взяли и вывалили в одно все что было

всем снова здрасьте!

Взлом инфраструктуры Docker Hub привёл к утечке 190 тысяч учётных записей https://opennet.ru/50584/

On Thursday, April 25th, 2019, we discovered unauthorized access to a single Hub database storing a subset of non-financial user data. Upon discovery, we acted quickly to intervene and secure the site. We want to update you on what we've learned from our ongoing investigation, including which Hub accounts are impacted, and what actions users should take. Here is what we’ve learned: During a brief period of unauthorized access to a Docker Hub database, sensitive data from approximately 190,000 accounts may have been exposed (less than 5% of Hub users). Data includes usernames and hashed passwords for a small percentage of these users, as well as Github and Bitbucket tokens for Docker autobuilds. Actions to Take: We are asking users to change their password on Docker Hub and any other accounts that shared this password. For users with autobuilds that may have been impacted, we have revoked GitHub tokens and access keys, and ask that you reconnect to your repositories and check security logs to see if any unexpected actions have taken place. You may view security actions on your GitHub or BitBucket accounts to see if any unexpected access has occurred over the past 24 hours -see https://help.github.com/en/articles/reviewing-your-security-log and https://bitbucket.org/blog/new-audit-logs-give-you-the-who-what-when-and-where This may affect your ongoing builds from our Automated build service. You may need to unlink and then relink your Github and Bitbucket source provider as described in https://docs.docker.com/docker-hub/builds/link-source/ We are enhancing our overall security processes and reviewing our policies. Additional monitoring tools are now in place. Our investigation is still ongoing, and we will share more information as it becomes available. Thank you, Kent

в почту прилетело?