еще варианты? помощь зала

Для статики github используй

+cloudflare

и какой воркфлоу? 1) запускаем в CI по коммиту билд и забираем из гитхаба проект из репы А 2) билдим статику и пушим проект в репу Б 3) запускаем pod с подключеным стораджем-репой Б негибко

мало ли че изменить надо, или статику по ftp закачивают... короче очень узкий юзкейс

ладно, я уже понял что рецепта готового нет, сори за спам

тоже мучался со статикой, не в контексте кубернетиса, просто с докером. было 3 варианта: 1. При обновлении репозитория с кодом в CI собирать еще и контейнер с nginx с включенной статикой 2. В контейнер с кодом добавить entrypoint, который при запуске делает rsync кода залитого в контейнер с volume, который расшарен с контейнером nginx 3. При обновлении репозитория с кодом в CI заливать статику (синхронизировать содержимое) с удаленным хранищием, типа S3 или подобного.

на чем остановился?

пока на rsync

но не нравиться volume использовать

их неудобно удалять при переносе

volume в смысле не приманученная папка, а image volume?

ну опять же докеры, контейнеры... вся эта виртуализация из-за пары файлов

volume в смысле не приманученная папка, а image volume?

всмысле docker volume

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

это volume который докер создает в /var/lib/docker/volumes

вот им вообще лучше не пользоваться

еще один вариант испоьзуем там где можем - статика отдается средствами прилоежния, а nginx её проксирует из контейнера с приложением и кеширует

приложения на node.js у нас так работают

хочется польностью уйти от volume

а чем плох volumes?

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

Любит оставаться на дсике после удаления изображения

Там даже маунтейнеры по-моему публично плевались

у это вот так version: '2' services: nginx: image: nginx volumes: - ./config/nginx.production.conf:/etc/nginx/nginx.conf ports: - '80:80' depends_on: - web volumes_from: - web web: build: context: . dockerfile: Dockerfile.prod env_file: .env environment: - RAILS_ENV=production - RAILS_MAX_THREADS=6 - WEB_CONCURRENCY=5 - PORT=9293 command: 'bundle exec puma -C config/puma.rb' volumes: - /app/public/assets

так нужно для картинок или для статики - css, js?

но это для docker. как сделать в kuberntes правильно, мне самому интересно :)

cat nginx.production.conf http { upstream application { server web:9293; } include mime.types; server { listen 80; server_name localhost; location ^~ /assets/ { root /app/public; gzip_static on; expires 1d; add_header Cache-Control public; } try_files $uri/index.html $uri @application; location @application { proxy_pass http://application; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host:$server_port; proxy_redirect off; } client_max_body_size 10M; keepalive_timeout 10; } }

для полноты картины nginx conf

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

а для mysql какие альтернативы? кроме папки на хосте

ну они могли просто не объявлять volume в докерфайле, и все

Те, кому важно хранить данные между запусками, выносили бы на хост в виде отдельной директории. А так я знаю, что у меня на ноутбуке неведома туча сранины (у каждого изображения-то свой volume), которую регулярно надо подчищать, и боюсь, что будет, если мне такую штуку придется выносить в прод.

папка на хосте плохая альтрентаива - у нее переносимость еще меньше чем у volume

тем, что тар придется самому запускать?

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

ну что, к какому консенсусу пришли? как лучше статику деплоить-то? )

подскажите, я вот думаю таки dcos разворачивать у себя на двух пеках с coreos, планирую туда подключать spark, kafka, cassandra и всякие свои микросервисы, dcos для этих дел самое оно или kubernetes лучше?

два пека - docker swarm

IMO

https://github.com/kubernetes/kubernetes/releases/tag/v1.4.0

они фигачат новые релизы быстрее чем я их настраиваю(

рановато еще https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md/#known-issues

вот эта фича интересная

http://kubernetes.io/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-alpha-feature

?

добрый день) у кого-нибудь возникали ошибки типа kernel: unregister_netdevice: waiting for vethf0a4e6b to become free. Usage count = 1, как вообще решить можно, обновлением ядра?

где-то я это видел...

где-то я это видел...

При использовании докера это всегда вылазиет :)

один из коллег с прошлой работы пытался это как-то исправить

http://kubernetes.io/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-alpha-feature

я вчера-позавчера в рамках допила этой фичи аж 3 PR зафигачил. В плане DaemonSet'ов https://github.com/kubernetes/kubernetes/pull/33451 https://github.com/kubernetes/kubernetes/pull/33523 Один, что поменьше, аж вмержили https://github.com/kubernetes/kubernetes/pull/33509

у них там, правда, какой-то косяк с CI сейчас :(

так что пока рано еще обновляться до 1.4.X?

Мы обновились, но чет AntyAffinity не работает

а что за фигня, я чет не в курил

Ну например через нее можно указать что бы две копии пода не запускались на одной ноде

или запускались но через "нехочу" и с ворчанием :)

ну так то полезная штука

да, еще в 1.4 шедулеры в альфа-версии должны быть, правка некоторых критичных багов, новая красивая гуя и еще по мелочи... так что штука зело полезная

еще в 1.4 Support for creating Jobs at specified times/dates (i.e. cron) is expected in 1.4

ну да, шедулеры короч

а тут спецов по openshift не появилось?

А как шедулеры будут реализованы? Они распределенные? Там есть какие-то гарантии?

“A scheduled job creates a job object about once per execution time of its schedule. We say “about” because there are certain circumstances where two jobs might be created, or no job might be created. We attempt to make these rare, but do not completely prevent them. Therefore, jobs should be idempotent.” Я правильно понимаю, что “оно может сработать, может не сработать, может сработать два раза. Вы уже не обесудьте” ?

ERROR: S client not available

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

или "да, мы понимаем что все должно быть красиво... в следующих релизах поправим"

ну вот AWS Lambda говорят, что сработает как минимум один раз. То есть может быть и два, но чтобы не сработало быть не может. То есть, если идемпотентная функция, то должно быть норм. С кубернетесом я так понял идемпотентность не поможет, ибо может вообще не выполниться.

в общем жду на гугле когда обновится, потестю

ну вот AWS Lambda говорят, что сработает как минимум один раз. То есть может быть и два, но чтобы не сработало быть не может. То есть, если идемпотентная функция, то должно быть норм. С кубернетесом я так понял идемпотентность не поможет, ибо может вообще не выполниться.

Это проблема вообще всех похожих систем. Нету очереди такой, что бы гарантировала именно ОДНУ доставку сообщения, а не КАК МИНИМУМ ОДНУ

Ну я понимаю. Но хотя бы одну кубернетес гарантирует или нет? Вот в чём вопрос.

а pod можно развернуть в режиме global?

или это как раз нужно делать через Димона :))

rnmv@rnmv-i5:~$ kubectl get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes 100.64.0.1 <none> 443/TCP 3h nginx 100.64.7.221 <pending> 80/TCP 7m уже почти 3 минуты на pending... После выполнения kubectl expose deployment nginx --port 80 --type LoadBalancer. Что может быть не так?

Кластер вроде успешно запустился

А как шедулеры будут реализованы? Они распределенные? Там есть какие-то гарантии?

я даже не заглядывал в спеку, но kubernetes держит один активный мастер и хранит все в etcd, тут по-моему особых вариантов-то нет.

Всем привет! Ребят, хочу совета спросить у тех, кто использует deis workflow. Как вы считаете лучше "поделить" апп на тест, стейдж и прод окружения?

Всем привет! Ребят, хочу совета спросить у тех, кто использует deis workflow. Как вы считаете лучше "поделить" апп на тест, стейдж и прод окружения?

лучше просто не использовать deis

кстати, официальный репозиторий с helm начали заполнять: https://github.com/kubernetes/charts

так что скоро возможно будет пакадж менеджер вменяемый

Почему не использовать? по мне так хорошая штука для билда и деплоя

Почему не использовать? по мне так хорошая штука для билда и деплоя

Он очень ограниченный. Но если тебе нужно задеплоить вордпрес, то наверное пойдет. В других случаях нужно использовать kubernetes

окай =) я учту, что ничего сложного лучше через deis не заливать. Вопрос-то в другом, есть те, кто использует и как разбивают на test/stage/prod =)

ну для начала прод и стейдж/тест держать в одном кластере как-то опасно

уф, спецы, подскажите, есть openshift пытаюсь скрестить его с jenkins прописал апи, ключ, проект, пытаюсь создать деплоймент конфиг через дженкинс, а оно мне в ответ в логах resourceVersion may not be set on objects to be created

согласен.. Если разбить на 3 отдельных кластера, то должно быть не плохо.. И деис повесить только на тестовые окружения... Хмм.

ну достаточно двух: тест+ стейдж и прод отдельно

ну в принципе да.. если апп в докер засунуть, то и тестровать его можно локалько!

ну а развернуть тестовое окружение(копию прода), можно и терраформом

никто не сталкивался с такой ошибкой? [root@srv-333770 ~]# kubectl version Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.7", GitCommit:"a2cba278cba1f6881bb0a7704d9cac6fca6ed435", GitTreeState:"clean", BuildDate:"2016-09-12T23:15:30Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} error: failed to negotiate an api version; server supports: map[], client supports: map[federation/v1beta1:{} autoscaling/v1:{} extensions/v1beta1:{} policy/v1alpha1:{} batch/v1:{} batch/v2alpha1:{} authentication.k8s.io/v1beta1:{} v1:{} authorization.k8s.io/v1beta1:{} componentconfig/v1alpha1:{} apps/v1alpha1:{} rbac.authorization.k8s.io/v1alpha1:{}]

неактуально:)

нашел решение -> расскажи сообществу

это касается видимо только google cloud

перед get-credentials надо задавать переменную окружения