Vadim
Ильдар
я проверял, из ARGS оно не умеет
жизнь боль, да invalid reference format
CHIP
куда можно копнуть, есть 2 инстанса на амазоне, t2.small и c4.large, на этих машинках крутятся докеры, запускаются они аналогично, но на t2.small информация обрабатывается на порядок быстрее, на c4.large контейнеры пипец тупят. кто-то сталкивался с подобным? Docker version 18.09.5, build e8ff056
John
всем привет, подскажите пожалуйста, это нормально давать контейнеру доступ выполнять команды на хосте? с большими ограничениями разумеется. или мне девопс потом все мозги выеет мол это несекьюрненько
Nazar
полагаю вы правы)
John
правы в чем простите? то есть можно?
Nazar
> или мне девопс потом все мозги выеет мол это несекьюрненько
Nazar
хотя
Nazar
опишите кейс
Nazar
мб это будет оправдано
John
идея в том что нужно запускать автотесты в контейнере, потому что на разных осях они по-разному работают. запускать через docker-compose. проблема в том что этот контейнер с тестами должен иметь возможность контролировать окружение, то есть убить базу например, чтобы проверить что хелсчек не 200 ОК постоянно шлет в независимости от того работает база или нет например) поэтому и хочется этому контейнеру дать управление. по сути мой киллер аргумент это то что это не продакшн юзадж, а ci/cd только
John
я в курсе за изоляцию контейнеров, и это все очень хорошо, но по-другому не вижу как
Viktor
А как вообще предполагается команды на хосте запускать?
Nazar
почему вы не хотите убить базу которая в контейнере?)
John
А как вообще предполагается команды на хосте запускать?
честно говоря пока не смотрел как, судя по стаковерфлоу как-то так ssh -l ${USERNAME} ${HOSTNAME} "${SCRIPT}"
John
почему вы не хотите убить базу которая в контейнере?)
то есть запросом убить? не сам контейнер положить?
Viktor
жутко выглядит
John
))
Nazar
то есть запросом убить? не сам контейнер положить?
можете сделать запрос который отрубит процесс базы
Anonymous
подскажите что не так с композом ? не создает базу данных(((
Anonymous
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
John
можете сделать запрос который отрубит процесс базы
проблема в том что база это частный случай, там много сторонних приложений используется, на все конечно можно написать, но это дольше чем просто контейнер рубануть
John
ахуеть...
ахуеть какое говнище я так полагаю?)
John
этим должен заниматься оркестратор, на худой конец тот же docker-compose.
Да, но нужно как то оркестратору дать понять что пришло время убить процесс
Григорий
Да, но нужно как то оркестратору дать понять что пришло время убить процесс
я могу не доконца понимать, но прописать kubectl delete pod —name=podname(не уверен насчет синтаксиса) чтобы дропнуть под с бд подойдет?
John
я могу не доконца понимать, но прописать kubectl delete pod —name=podname(не уверен насчет синтаксиса) чтобы дропнуть под с бд подойдет?
Написать не проблема, вопрос в том насколько это плохо давать возможность контейнеру/поду делать это
Григорий
это можно делать и из ci
Andor
с удивлением обнаружил что в FROM можно подставлять переменные из ARG
Andor
но при этом делать типа COPY --from=composer:${composer_version} /usr/bin/composer /usr/local/bin/composer - нельзя
Andor
FROM php:${php_version}-fpm-stretch as php-installer COPY --from=composer:1.8.5 /usr/bin/composer /usr/local/bin/composerFROM - валидный, а COPY фейлится
Andor
а пишут что должно работать :/
Andor
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хм, а вот так работает :/
Ильдар
Вопросы про докер есть?
Ильдар
Задавай)
Anonymous
Задавай)
А можно мне вопрос?)
Anonymous
Ранее остался без ответа.
Anonymous
Дебиан 9.докер последний. Оверкоммит=1 и свопинесс=0 но докер контейнеры жрут своп при свободной 50% ОЗУ
George
У меня эльпайн их не создавал бд. На базе их убунты образ - все ок. При этом их же эльпайн, если подмонтировать базу уже существующую - отлично
Anonymous
Помогите разобраться с моим композом
George
Что ты делаешь, человече. Грузи на пейстбин
Anonymous
Что ты делаешь, человече. Грузи на пейстбин
Я в докере не в зуб ногой, объясните как лучше все это сделать 🙏🏻
George
pastebin есть такой сайт. Компоуз грузи туда
Mike
George
Пруф
George
Mike
принимается
George
Ненавижу инглиш 🔥 🔥
George
https://pastebin.com/eTvCrk17
Выкинь INFLUXDB_DB="homeassist"
George
Мне кажется, что эта опция годится, если база уже есть. В теории можешь запустить инфлакс ВООБЩЕ БЕЗ ВСЕХ ПЕРЕМЕННЫХ. Он должен создать БД по умолчанию. Ну, и смотри логи контейнера. Если он не может создать, что он явно напишет
George
volumes:  influxdb:    external: true
George
И почему так сделано? External:true лишнее, кмк
Anonymous
без всего тоже не создает
George
Быть того не может. Логи дай
lm
возможно как-то пушить в кастомный репозиторий и скипать образы из официальных источников? у меня не такой быстрый интернет-канал, а пуш что-то подвис)
Andor
если твой репозиторий умеет пуллить с публичных, то сделай это, а потом пуш свой
Anonymous
Нет, просто докер
Ильдар
Так пробовал? https://docs.docker.com/config/containers/resource_constraints/#--memory-swap-details
lm
если твой репозиторий умеет пуллить с публичных, то сделай это, а потом пуш свой
это registry v2. в него возможно запуллить перед пушем туда?
lm
что-то типа такого нужно сделать для каждого образа? docker tag codemazeblog/accountownerapp:latest my-registry:50000/codemazeblog/accountownerapp:latest docker push my-registry:50000/codemazeblog/accountownerapp
simplemice.eth
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