Docker и все все все

Ставил на Ubuntu 16.04. И да, в логах есть инфа о том, что «CNI failed to retrieve network namespace». Видимо, если я хочу получить что-то вменяемое, нужно воспользоваться чем-то вроде minikube. А production решение получить нереально без мощной поддержки со стороны крупного облачного хостинга

Docker и все все все

а какой у вас был выбор? Почему именно Nomad вас заинтересовал?

И что значит «без жестко закрепленного мастера»? Имеется в виду наверно Raft? В Swarm например тоже нет захардкоженного мастера, есть набор менеджеров, какждый из которых может взять на себя роль лидера на некоторый период. И да, в Swam все ноды тоже равноправны, но можно принудительно уменьшить права ноды, чтобы она всегда была только рабочей нодой.

Docker и все все все

$ kubectl describe pod

$ kubectl describe pod nginx-5f9f9d8465-dxtvz
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulMountVolume 1m kubelet, kub-2 MountVolume.SetUp succeeded for volume "default-token-vmtmg"
Normal Scheduled 1m default-scheduler Successfully assigned nginx-5f9f9d8465-dxtvz to kub-2
Warning FailedCreatePodSandBox 1m (x8 over 1m) kubelet, kub-2 Failed create pod sandbox.
Warning FailedSync 1m (x8 over 1m) kubelet, kub-2 Error syncing pod
Normal SandboxChanged 1m (x8 over 1m) kubelet, kub-2 Pod sandbox changed, it will be killed and re-created.


Что за причина все равно непонятно. Зато увидел, что у меня с Flannel что-то неладное:

$ kubectl get pods --all-namespaces

$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system etcd-kub-1 1/1 Running 0 18m
kube-system kube-apiserver-kub-1 1/1 Running 0 17m
kube-system kube-controller-manager-kub-1 1/1 Running 0 18m
kube-system kube-dns-545bc4bfd4-cnl7h 0/3 ContainerCreating 0 18m
kube-system kube-flannel-ds-9f55b 0/1 CrashLoopBackOff 8 17m
kube-system kube-flannel-ds-brfst 0/1 CrashLoopBackOff 7 16m
kube-system kube-flannel-ds-s6vr4 0/1 CrashLoopBackOff 7 16m
kube-system kube-proxy-76fr5 1/1 Running 0 18m
kube-system kube-proxy-7cxs7 1/1 Running 0 16m
kube-system kube-proxy-z44fz 1/1 Running 0 16m
kube-system kube-scheduler-kub-1 1/1 Running 0 18m


Куда дальше копать? :)

Docker и все все все

CNM — Container Network Model. На хабре есть заметка о CNI, в которой есть ссылка на сравнение CNM vs. CNI.

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

К тому же, в упомянутой статье в конце автор приводит мысль о том, что релиз Docker 1.12 существенно улучшил сетевую подсистему Docker, сделав ее вполне функциональной по сравнению с другими.

Docker и все все все

ок, попробую еще раз. Отпишусь потом :)

Docker и все все все

А ошибку какую возвращал?

никакую, просто не поднималось. На воркере можно было видеть то, что я статье привел в пример. А мастер показывал это:

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-569477d6d8-ks262 0/1 ContainerCreating 0 5m
nginx-deployment-569477d6d8-tpcg6 0/1 ContainerCreating 0 5m
nginx-deployment-569477d6d8-wj98c 0/1 ContainerCreating 0 5m


Docker и все все все

это слишком hard :) Для Ubuntu есть more easy way: www.techrepublic.com/article/how-to-quickly-install-kubernetes-on-ubuntu

Хотя я поднял 3 виртуалки с Ubuntu и попробовал поднять кластер Kubernetes. Он вроде заработал, ноды начали друг друга видеть. Но поднять сервис из трех реплик nginx он не смог. Может памяти не хватило? Я использовал такие виртуалки (1024 мб оперативы по дефолту):

Vagrantfile

Vagrant.configure('2') do |config|

  config.vm.box = 'bento/ubuntu-16.04'

  config.vm.network 'private_network', type: 'dhcp'

  %w(
    kub-1
    kub-2
    kub-3
  ).each do |host_name|
    config.vm.define host_name do |host|

      host.vm.hostname = host_name

      # install Docker
      host.vm.provision 'docker'

      # install Kubernetes
      host.vm.provision 'shell', :privileged => true,
        inline: <<-EOF
          curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add
          echo 'deb http://apt.kubernetes.io/ kubernetes-xenial main' > /etc/apt/sources.list.d/kubernetes.list
          apt-get update
          apt-get install -y kubelet kubeadm kubectl kubernetes-cni
          swapoff --all  # demands by kubectl
        EOF

    end

  end
  
end

Docker и все все все

Возможно вы обладаете несколько устаревшей информацией, потому что все, что вы перечислили, в Swarm уже есть, причем из коробки.

Ну разве что про кастомные ресурсы я не знаю, но это что-то очень специфическое и кастомное :)

Docker и все все все

k8s значительно больше умеет.

Чаще всего именно этот довод я слышу от тех, кто предпочитает использовать Kubernetes. А вы можете привести конкретный пример полезной фичи, которую вы действительно используете, и из-за отсутствия которой вы не можете использовать Swarm?

Docker: деплой master-slave конфигурации PostgreSQL

во времена написания комментария в Docker еще не было отдельных сущностей с названием 'volume', и было вполне очевидно, что под выражением «мы подключаем к контейнеру volume с папкой на хосте» означает маунтинг папки с хоста внутрь контейнера, например, -v /data:/data

Пробел в знаниях основ веб-разработки

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

Как разделить окружение для сборки и запуска сервиса в Docker сегодня и как это cделать завтра

использую докеризированные команды

Вы могли бы привести пример?

Как разделить окружение для сборки и запуска сервиса в Docker сегодня и как это cделать завтра

Согласен, изящность немного хромает из-за жирного RUN. Но такой способ мне кажется предпочтительнее использования нескольких Dockerfile и сложной процедуры сборки образа.

Как разделить окружение для сборки и запуска сервиса в Docker сегодня и как это cделать завтра

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

FROM golang:1.8.1-alpine
WORKDIR /go/src/github.com/username/project
ADD . ./
# Устанавливаем зависимости, необходимые для сборки
RUN apk add --no-cache --virtual .build-requirements \
    git \
    make \
# Запускаем сборку
    && make build \
# удаляем установленные выше пакеты
    && apk del .build-requirements

Bash on Windows: практические опыты по скрещиванию ежей и ужей

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

Docker, установленный на винду «нативно», из баша не запустился. Хотя, возможно я не учел тот факт, что под виндой бинарник докера может называться docker.exe. Если так, то создание соответствующего alias в баше может помочь.

Как вернуться в кодеры, когда за сорок

Самое сложное в таком возрасте — забыть о разнице лет и начать перенимать знания и опыт у более молодого и опытного коллеги. Без наставника постигать мастерство написания кода гораздо сложнее.

What the flask?

такое впечатление, что на слайде пропущено слово WHERE.

Данный пример явно выдран из контекста. Скорее всего это второй запрос и двух после применения refetch_related — что на самом деле является как раз оптимизацией. Альтернатива такому запросу — запрос каждой сущности из table (точнее из другой, которая заранее читается при помощи prefetch_related) по одному.

What the flask?

если нужна простая страница в вебе, то вам и Flask/Django не нужны. Фреймворки же не просто так фпеймворками называются — у них есть предназначение. И если под предназначением понимается создание пусть даже небольшого API из нескольких методов, то я предпочту не держать все в одном файле.

Будущее мобайла — не приложения, а браузеры

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

Будущее мобайла — не приложения, а браузеры

Так не произойдёт ни в ближайшее время, ни в обозримом будущем. Вендоры (Apple, Google, Microsoft и др.) всегда будут продвигать свои способы не только оптимизации приложений (из-за которых нативные приложения всегда будут работать на порядок быстрее и экономичнее по отношению к заряду аккумулятора), но и свои способы взаимодействия с пользователем. Последние всегда будут отличаться, и не только из-за ограничений патентов на тот или иной способ, но и потому что каждый вендор будет стремиться реализовать свой собственный уникальный интерфейс, который по их мнению должен быть лучше (не без оснований можно быть уверенным), чем у конкурентов.

В итоге, продвигая свою платформы, вендоры будут всячески тормозить процессы стандартизации и развития браузерных технологий. Такое поведение мы можем наблюдать на примере скорости развития JavaScript (то огромное количество новых возможностей, что в нем появилось за последние 20 лет) и скорости появления новых костылей фреймворков, что только подчеркивают всю обреченность такого подхода.