Свой облачный хостинг за 5 минут. Часть 1: Ansible, Docker, Docker Swarm

    Cloud hosting

    Привет Хабр! Последние 1.5 года я работал над своим проектом, которому был необходим надежный облачный хостинг. До этого момента я больше 10 лет занимался веб-программированием и когда я решил построить свой хостинг у меня были относительно поверхностные знания в этой области, я и сейчас не являюсь системным администратором. Все что я буду рассказывать может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.

    Моя цель – дать вам список инструментов и общее понимание, что бы вы знали от чего отталкиваться, если у вас появится необходимость в собственном облачном хостинге. При выборе используемых инструментов я ориентировался на простоту, качество документации и стабильность. Прежде, чем использовать все это у себя в продакшене, вам определенно стоит проконсультироваться с системным администратором (я использую некоторые компоненты, которые находятся в статусе «BETA» (июнь 2015)).

    Содержание



    Зачем свой хостинг?


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

    Вторая причина заключается в специфике моего проекта, он связан с приватностью персональных данных. У меня нет причин кому-то просто доверять свои данные, а своих пользователей тем-более. Меня очень волнует этот вопрос, и я обеспокоен тем, что ему уделяется так мало внимания.

    Последняя причина в целях и ориентирах у стартапа в Российских реалиях. Здесь основная цель – начать зарабатывать деньги и выйти в плюс. Нет прибыли – нет стартапа, есть убыточное хобби. Поэтому, третья причина – это стоимость. У меня сейчас ~9Tb трафика и ~5Tb данных, которые я регулярно обрабатываю, обходится мне все это ~100$/месяц (можете посчитать сколько это будет стоить на AWS). Я знаю, что в следующем месяце у меня будет такая же стоимость, а проект я строю на свои деньги.

    Подготовка


    Первое, что необходимо сделать – раздобыть 3 сервера в одном датацентре (они должны находится как можно ближе друг к другу, что бы ping между ними был минимальный). Не имеет значения, будут это виртуальные выделенные сервера (на время тестирования) или настоящие и у какого провайдера вы их арендуете. Я заказал у DigitalOcean, выбрал установку Debian 8.1 x64 и указал добавить свой SSH ключ:



    Установка закончена и у нас в распоряжении 3 «голых» сервера:



    Ansible


    Как вы уже поняли, мы будем использовать Ansible для конфигурирования наших серверов. Если вы не знаете что это такое и как этим пользоваться, то на Хабре есть ответы на эти вопросы:

    1. Система управления Ansible
    2. Ansible
    3. Ansible — давайте попробуем

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

    Ansible не единственная система управления конфигурациями (есть Puppet, Chef, Salt и т.д.), так почему именно она?

    Как я написал выше, один из приоритетов при выборе инструментов – простота. На управляемые машины не надо устанавливать клиенты (все работает через SSH), язык сценариев предельно прост, у проекта свежая и подробная документация, а код модулей написан на Python (что для нас преимущество, потому что Python является основным языком в стартапе).

    Мысли о простоте
    Вообще для меня простота является признаком глубокого понимания предмета. Если один человек (знакомый с предметом), не может объяснить другому человеку (с предметом не знакомому), как он работает, значит он сам до конца не понимает этот предмет.

    Это хорошо раскрыто в книге Стива Возняка – «Cтив Джобс и Я», там отец начинает рассказывать принципы электротехники Стиву, когда он еще не достиг четырех лет (книга будет интересна всем инженерам, даже если вас не интересует история Apple).

    На этом этапе Ansible должен быть установлен на вашей клиентской машине (инструкция). Мне, на OS X 10.9, для этого понадобилось выполнить всего 2 команды:

    » sudo easy_install pip # если у вас еще не установлен PIP
    » sudo pip install ansible
    

    Проверяем, что все ок:

    » ansible --version
    ansible 1.9
      configured module search path = None
    


    Docker


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

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

    Мы можем запустить 20 контейнеров с 1-ой версией нашего веб-приложения, 2 контейнера со 2-ой версией и распределив между ними нагрузку, показать новую версию только ~10% посетителей, оценив стабильность работы и отзывы пользователей.

    Сейчас вам необходимо установить Docker на клиентскую машину, он понадобится нам для управления будущим кластером Docker'ов. Самый простой способ сделать это – скачать GUI клиент Kitematic (доступен для Mac OS X 10.9+ и Windows 7+ 64-bit), зайти в главное меню и выбрав «Install Docker Commands» установить консольные комманды Docker'а.



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

    » docker version  
    Client version: 1.6.2
    Client API version: 1.18
    Go version (client): go1.4.2
    Git commit (client): 7c8fca2
    OS/Arch (client): darwin/amd64
    


    Docker Swarm


    Docker Swarm
    Наконец-то мы дошли до самого интересного, до того, что придаст нашему хостингу «облачности». Странно, но я не нашел никакой информации о Docker Swarm на Хабре.

    Docker Swarm служит для объединения множества Docker хостов в один виртуальный хост и делает это элегантно. Docker Swarm предоставляет REST API интерфейс, совместимый с Docker API. Таким образом, все инструменты, которые работают с API Docker'a (клиент Docker'a, Dokku, Compose, Krane, Flynn, Deis, DockerUI, Shipyard, Drone, Jenkins и т.д.), смогут работать с Docker Swarm, не подозревая о том, что за ним стоит кластер Docker'ов, а не одна машина.

    Давайте уже построим наше облако и на практике посмотрим на что способен Docker Swarm.

    Приступаем


    К этому моменту у вас на клиентской машине должен быть установлен Ansible и Docker. В наличии должно быть 3 сервера с авторизацией по ключу и Debian 8.1 x64 на борту (вы можете использовать любой другой дистрибутив, внеся небольшие изменения в сценарии). Я подготовил набор сценариев для Ansible, которые сделают всю работу за вас, поэтому вам не понадобится много времени.

    Скачиваем набор сценариев или клонируем репозиторий:

    » git clone https://github.com/vkozlovski/ansible-cloud-hosting
    » git checkout v1.x
    » cd ansible-cloud-hosting
    

    Открываем файл stage и заменяем в нем IP адреса на IP своих серверов:

    [cloud]
    188.166.16.70   debian_release=testing   hostname=debian1
    188.166.99.31   debian_release=testing   hostname=debian2
    128.199.59.102  debian_release=testing   hostname=debian3
    

    Для того, что бы Docker Swarm мог соединяться с нодами Docker'a, они должны быть доступны снаружи (по умолчанию на 2375-ом порту для HTTP и на 2376-ом для HTTPS). Также нам надо сделать доступным снаружи и Docker Swarm Manager, что бы мы могли управлять кластером. HTTP нам для этих целей не подходит (мы же строим облако для себя, а не любого интернет-пользователя), остаётся HTTPS, а точнее TLS (подробнее можно почитать в официальной документации).

    Принцип работы следующий: мы создаём свой центр сертификации (далее ЦС), подписываем сертификаты для сервера и клиента Docker'a. После этого «демон» докера принимает соединения от клиентов, сертификат которых подписан тем же ЦС, что и сертификат «демона». Клиент Docker'а выполняет такую же проверку и подключается только к тем серверам Docker'a, сертификат которых подписан тем же ЦС. Docker Swarm Manager использует такую же схему. Таким образом обеспечивается аутентификация и безопасность нашего мини-облака.

    Единственное, что вам требуется сделать, это сгенерировать ключи для вашего ЦС (все остальное выполнится в автоматическом режиме). Просто выполните следующие команды из корневой директории проекта (пароль, который вы укажите, необходимо запомнить, он нам понадобится) и заполните ответы на вопросы (тут нет никаких конкретный требований, домен можете указать любой):

    » openssl genrsa -aes256 -out certs/ca/ca-key.pem 4096
    » openssl req -new -x509 -days 365 -key certs/ca/ca-key.pem -sha256 -out certs/ca/ca.pem
    

    Осталось заполнить значения некоторых переменных в файле:

    group_vars/all.yml
    certs:
      ca:
        password: "YOUR PASSWORD HERE"
    
    docker_swarm:
      # docker run --rm swarm create
      token: "YOUR DOCKER SWARM TOKEN HERE"
      manager: "YOU DOCKER SWARM MANAGER IP HERE"
    
    ssh:
      users:
        # user for ansible
        - user: "support"
          shell: "/bin/zsh" # for oh-my-zsh
          groups: "sudo"
          # mkpasswd --method=SHA-512
          password: "YOUR PASSWORD HERE"
          # cat ~/.ssh/id_rsa.pub
          key: "YOUR PUBLIC KEY HERE"
    


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

    Переменная docker_swarm.token должна содержать идентификатор нашего будущего кластера, который можно сгенерировать следующей командой:

    » docker run --rm swarm create
    6856663cdefdec325839a4b7e1de38e8
    

    Переменная docker_swarm.manager должна содержать IP адрес хоста, где будет запущен Docker Swarm Manager (укажите IP адрес любого из ваших серверов).

    В сценариях Ansible указано, что необходимо создать пользователя support, добавить его в группу sudo и запретить root'у возможность авторизации по SSH. Значение переменной ssh.users[].password должно быть хешем пароля для указанного выше пользователя. Для того, что бы его получить, необходимо выполнить следующую команду на любой Linux машине (можете зайти на один из ваших серверов по SSH и выполнить ее):

    » mkpasswd --method=SHA-512
    Password: 
    $6$n0lQGWy2s5437ns1$nczULrrTw5r.TmhEI/xBz5xYEHWyMbtbQhAJoWshv0rFjSoRxLYZh0zDoMwVM.ZFnChx7ym.4.r182EOIn9Ec/
    

    Значение ssh.users[].key должно быть вашим публичным ключом, который по умолчанию находится тут ~/.ssh/id_rsa.pub:

    ~/.ssh/id_rsa.pub
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDDakR6/NJuIxJGpWZiV5QODuRacuh4VoIdzeOUlH+MC1xxFf/U74gfumoQ1k62d4S0qPqnlpJVqRNg7mQo0CCguujVRuOP+FbRMjdQbbAEfDAjxkSuKXRWnChg6Ds4MX0RO9WUB9pQLrCmbPpI8A0l0zaNi6mp6TaXWCoMPrgk1OfuTYDBTgQya/MtKjjPnWFEdgwTvB3hVusCU83854Gju9OX4I5ucejy/f8/IWGUIFt8miLisrYnDcdFvY/ThzX7E2h4lzsc8JK6ltywyoHVScl3Vdgf1/WbScEnQYWJZk/h2zWDqdFlte/elov7l3yfJDN0axF+dC6BqJGfZMFQsN6xPWHoG8OCPaH2HmTY3XNpQNRLJR5GFWwVriIBDe+GyVjtjzb1/BLdu0WJatv6/PYMsEfArYBgnQ/bHYgfFLF0GPq6nBGJbngytv7C5crBljZAvnC86HQN5sGPbZWfkKdvoG5MbbJYwqFvaD2BEjlXMurbCX4ERrRUHC9875XufaCvdpCiSWaU4S5PM8nr2QCF3co0EtL0bkiciyv95eU0HoQ3cYhPNGwUMxntPp/3z0KRqeSBHPnvV5pmXOwP/xUHxEIvDbqCXtTc3y96iDKZ1T8+jPH1aif6ooVUwmogTHDd1DcW+APtMkqRHdZ7r33wKAYJfNopd+0P8rYF2w==
    


    Пример заполненного файла конфигурации можете глянуть ниже:

    group_vars/all.yml
    certs:
      ca:
        password: "12345"
    
    docker_swarm:
      # docker run --rm swarm create
      token: "6856663cdefdec325839a4b7e1de38e8"
      manager: "188.166.16.70"
    
    ssh:
      users:
        # user for ansible
        - user: "support"
          shell: "/bin/zsh" # for oh-my-zsh
          groups: "sudo"
          # mkpasswd --method=SHA-512
          password: "$6$n0lQGWy2s5437ns1$nczULrrTw5r.TmhEI/xBz5xYEHWyMbtbQhAJoWshv0rFjSoRxLYZh0zDoMwVM.ZFnChx7ym.4.r182EOIn9Ec/"
          # cat ~/.ssh/id_rsa.pub
          key: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDDakR6/NJuIxJGpWZiV5QODuRacuh4VoIdzeOUlH+MC1xxFf/U74gfumoQ1k62d4S0qPqnlpJVqRNg7mQo0CCguujVRuOP+FbRMjdQbbAEfDAjxkSuKXRWnChg6Ds4MX0RO9WUB9pQLrCmbPpI8A0l0zaNi6mp6TaXWCoMPrgk1OfuTYDBTgQya/MtKjjPnWFEdgwTvB3hVusCU83854Gju9OX4I5ucejy/f8/IWGUIFt8miLisrYnDcdFvY/ThzX7E2h4lzsc8JK6ltywyoHVScl3Vdgf1/WbScEnQYWJZk/h2zWDqdFlte/elov7l3yfJDN0axF+dC6BqJGfZMFQsN6xPWHoG8OCPaH2HmTY3XNpQNRLJR5GFWwVriIBDe+GyVjtjzb1/BLdu0WJatv6/PYMsEfArYBgnQ/bHYgfFLF0GPq6nBGJbngytv7C5crBljZAvnC86HQN5sGPbZWfkKdvoG5MbbJYwqFvaD2BEjlXMurbCX4ERrRUHC9875XufaCvdpCiSWaU4S5PM8nr2QCF3co0EtL0bkiciyv95eU0HoQ3cYhPNGwUMxntPp/3z0KRqeSBHPnvV5pmXOwP/xUHxEIvDbqCXtTc3y96iDKZ1T8+jPH1aif6ooVUwmogTHDd1DcW+APtMkqRHdZ7r33wKAYJfNopd+0P8rYF2w=="
    


    Теперь мы готовы приступить к построению долгожданного облака:

    » ansible-playbook -i stage site.yml -u root
    

    Из-за того, что мы отключили возможность авторизации root'ом, а также добавили пользователя support (это прописано в сценариях Ansible), все последующие запуски надо выполнять с флагами -s (sudo) и -K (для запроса пароля для sudo):

    » ansible-playbook -i stage site.yml -u support -s -K
    


    Проверка и использование


    Мы готовы к проверке нашего новоиспеченного облака:

    » docker -H tcp://188.166.16.70:8000 --tlsverify=true --tlscacert=certs/ca/ca.pem --tlscert=certs/docker/cert.pem --tlskey=certs/docker/key.pem info
    Containers: 4
    Images: 3
    Storage Driver: 
    Role: primary
    Strategy: spread
    Filters: affinity, health, constraint, port, dependency
    Nodes: 3
     debian1: 188.166.16.70:2376
      └ Containers: 2
      └ Reserved CPUs: 0 / 1
      └ Reserved Memory: 0 B / 519.2 MiB
      └ Labels: executiondriver=native-0.2, kernelversion=3.16.0-4-amd64, operatingsystem=Debian GNU/Linux stretch/sid, storagedriver=aufs
     debian2: 188.166.99.31:2376
      └ Containers: 1
      └ Reserved CPUs: 0 / 1
      └ Reserved Memory: 0 B / 519.2 MiB
      └ Labels: executiondriver=native-0.2, kernelversion=3.16.0-4-amd64, operatingsystem=Debian GNU/Linux stretch/sid, storagedriver=aufs
     debian3: 128.199.59.102:2376
      └ Containers: 1
      └ Reserved CPUs: 0 / 1
      └ Reserved Memory: 0 B / 519.2 MiB
      └ Labels: executiondriver=native-0.2, kernelversion=3.16.0-4-amd64, operatingsystem=Debian GNU/Linux stretch/sid, storagedriver=aufs
    Execution Driver: 
    Kernel Version: 
    Operating System: 
    CPUs: 3
    Total Memory: 1.521 GiB
    Name: 
    ID: 
    Http Proxy: 
    Https Proxy: 
    No Proxy:
    

    Ура! Я почти дописал эту большую статью, а вы успешно закончили построение своего облака.

    Если у вас появится необходимость, то вы можете подключаться к любому из Docker хостов отдельно:

    Пример
    » docker -H tcp://128.199.59.102:2376 --tlsverify=true --tlscacert=certs/ca/ca.pem --tlscert=certs/docker/cert.pem --tlskey=certs/docker/key.pem info
    Containers: 2
    Images: 7
    Storage Driver: aufs
     Root Dir: /var/lib/docker/aufs
     Backing Filesystem: extfs
     Dirs: 11
     Dirperm1 Supported: true
    Execution Driver: native-0.2
    Kernel Version: 3.16.0-4-amd64
    Operating System: Debian GNU/Linux stretch/sid
    CPUs: 1
    Total Memory: 494.5 MiB
    Name: debian1
    ID: 5XPE:2VWX:QCSA:J3PJ:WMN7:EDXX:3TSS:7K7K:XU4R:Z3AX:TRVX:VTUQ
    WARNING: No memory limit support
    WARNING: No swap limit support
    


    Но мы же не для этого прошли весь этот путь, правда? Давайте попробуем запустить несколько экземпляров Nginx в нашем облаке:

    » docker -H tcp://188.166.16.70:8000 --tlsverify=true --tlscacert=certs/ca/ca.pem --tlscert=certs/docker/cert.pem --tlskey=certs/docker/key.pem run -d -p 80:80 --name nginx1 nginx
    bb49018b697fca975d10a5ec31ad2fed65ed12b3ad8fbd61e64474187d8bc6ed
    
    » docker -H tcp://188.166.16.70:8000 --tlsverify=true --tlscacert=certs/ca/ca.pem --tlscert=certs/docker/cert.pem --tlskey=certs/docker/key.pem run -d -p 80:80 --name nginx2 nginx
    2bd86ff97c35d431e9db7f0571d65e17893aefd1d18b1b52194c100a22a49937
    


    Проверяем:
    Nginx

    Давайте попробуем запустить еще 2 экземпляра Nginx:

    » docker -H tcp://188.166.16.70:8000 --tlsverify=true --tlscacert=certs/ca/ca.pem --tlscert=certs/docker/cert.pem --tlskey=certs/docker/key.pem run -d -p 80:80 --name nginx3 nginx
    622b4e199c700cae663bf2e2f326918f94a0cd016c27dc9ff39f4ec4abf7bdb1
    
    » docker -H tcp://188.166.16.70:8000 --tlsverify=true --tlscacert=certs/ca/ca.pem --tlscert=certs/docker/cert.pem --tlskey=certs/docker/key.pem run -d -p 80:80 --name nginx4 nginx
    FATA[0001] Error response from daemon: unable to find a node with port 80 available 
    

    Как мы видим 3-ий экземпляр запустился, а вот 4-ый нет: FATA[0001] Error response from daemon: unable to find a node with port 80 available. Docker Swarm Scheduler видит, что нет хостов со свободным 80-ым портом.

    Мы можем посмотреть, какие контейнеры сейчас выполняются у нас в кластере и удостовериться, что каждая копия Nginx была запущена на разной машине:

    » docker -H tcp://188.166.16.70:8000 --tlsverify=true --tlscacert=certs/ca/ca.pem --tlscert=certs/docker/cert.pem --tlskey=certs/docker/key.pem ps                                                      1 ↵
    CONTAINER ID        IMAGE                  COMMAND                CREATED             STATUS              PORTS                                NAMES
    622b4e199c70        nginx:latest           "nginx -g 'daemon of   5 minutes ago       Up 5 minutes        128.199.59.102:80->80/tcp, 443/tcp   debian3/nginx3                 
    2bd86ff97c35        nginx:latest           "nginx -g 'daemon of   16 minutes ago      Up 16 minutes       188.166.16.70:80->80/tcp, 443/tcp    debian1/nginx2                 
    bb49018b697f        nginx:latest           "nginx -g 'daemon of   17 minutes ago      Up 17 minutes       188.166.99.31:80->80/tcp, 443/tcp    debian2/nginx1                 
    148eef0bbe02        library/swarm:latest   "/swarm manage --tls   2 hours ago         Up 2 hours          188.166.16.70:8000->2375/tcp         debian1/docker-swarm-manager   
    3545322d27b7        library/swarm:latest   "/swarm join --addr=   2 hours ago         Up 2 hours          2375/tcp                             debian2/docker-swarm           
    faaa78cbedba        library/swarm:latest   "/swarm join --addr=   2 hours ago         Up 2 hours          2375/tcp                             debian3/docker-swarm           
    0fee12f6a473        library/swarm:latest   "/swarm join --addr=   2 hours ago         Up 2 hours          2375/tcp                             debian1/docker-swarm 
    

    Возможности Docker Swarm на этом не заканчиваются, а только начинаются (об этом можно почитать тут и тут).

    Как я писал в начале статьи, моя цель – дать вам список инструментов и общее понимание, что бы вы знали от чего отталкиваться и я надеюсь, что она достигнута.

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

    На этом все. Всем спасибо за внимание. Стабильных вам облаков и удачи!

    Подписывайтесь на меня в Twitter, я рассказываю о работе в стартапе, своих ошибках и правильных решениях, о python и всём, что касается веб-разработки.

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

    Подробнее
    Реклама
    Комментарии 42
    • 0
      Советую вам посмотреть на docker-machine, думаю, что потребность в ansible отпадет docs.docker.com/swarm/install-w-machine
      • 0
        Я знаком с Docker Machine, он мог бы решить задачу, описанную в этой статье, но не смог бы решить остальные мои задачи о которых я планирую написать в следующих частях.

        Сейчас я описал лишь небольшую часть облака и в будущем решение станет более очевидным.
      • 0
        Все же сертификатики лучше генерировать в специальных тулзах, например xca.
        • +1
          чем лучше?
          • 0
            Тем, что удобнее. Особенно если сертификатов более одного. А рано или поздно так и будет.
        • 0
          Ключики сварма стоит покидать в ~/.docker для удобства
          • 0
            Если кластер у вас один или несколько подписанных одним ЦС, а ваша клиенсткая машина хорошо защищена, то да.

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

            swarm:
            	@(docker -H tcp://188.166.16.70:8000 --tlsverify=true --tlscacert=certs/ca/ca.pem --tlscert=certs/docker/cert.pem --tlskey=certs/docker/key.pem info)
            


            • 0
              А что за зашифрованный образ? Не поделитесь в двух словах, как это выполнено архетектурно/технически? Интересная идея но как-то всё руки не доходят организовать себе что-то похожее)
              • 0
                Если у вас OS X, то информация есть на Хабре, например тут.
          • 0
            третья причина – это стоимость. У меня сейчас ~9Tb трафика и ~5Tb данных, которые я регулярно обрабатываю, обходится мне все это ~100$/месяц (можете посчитать сколько это будет стоить на AWS)

            Поделитесь расчётами.
            • +1
              Хранилище: 0,0300$ * 1024Mb * 5Tb = 153,6$
              Трафик: 0,090$ * 1024Mb * 9Tb = 829,44$
              = 983,04$/месяц

              В указанные ~100$ входят еще 16 честных ядер, 64Gb оперативной памяти, 480Gb SSD и 60Tb трафика, которые я не стал тут добавлять в стоимость.
              • +13
                Вообще тот, кто пытался посчитать точную стоимость услуг на AWS, больше не только в цирке, но и в жизни не смеётся.
            • 0
              Спасибо, отличная статья, продолжайте в том же духе.
              Но вот лично для меня все статьи про docker и т.п. не вдохновляют по одной простой причине: отдают незаконченностью. Вернее они рассказывают, как это круто, но я ещё не встречал статей, где есть полностью построенный какой-то проект, пусть и тестовый, сферический в вакууме. Тестовый, но реальный.
              Спросите, а о чём это он? Да ну хотя бы LEMP, а ещё лучше load balancer + 2-3 node.js + MongoDB replica set. Или я чего-то совсем не понимаю, да…
              • 0
                Докер это не панацея, строго говоря, не всем он подходит, совсем суровые пацаны вообще свои решения пишут, не хуже, я встречал таких. Это скорее показательный пример, философский взгляд, если хотите, чтобы в тему въехать, ну а дальше уже каждый хохочет как хочет.
                • 0
                  Я ж не спорю, что каждому своё…
                  Просто практически все статьи заканчивают тем, что вот, мы установили докер, теперь всё круто. Всё. Ну т.е. совсем всё.
                  И нет статей, как это потом в реальности использовать. Вот что печалит.
                  • 0
                    Наверное потому, что ниже уже идут совершенно рядовые рабочие вопросы, которые многократно обсасывались уже.

                    Непонятно, что ещё писать, есть некий пул, в нем крутятся воркеры, вдруг набежал-набежал клиент, в пуле поднялись ещё с десяток воркеров, все счастливы, ничего не тормозит, программеры получают премии, покупают яхты и спорткары (ну, пока не проснулись).
                    • 0
                      У рядовых рабочих вопросов есть огромное количество нюансов, которые совсем не очевидны когда ты только начинаешь использовать Docker. Появление Machine, Swarm, Compose, Network, Orca, плагинов для Docker Engine обусловлено тем, что при использовании докера на реальных проектах существует масса проблем, особенно если ты переходишь к микросервисной архитектуре и количество контейнеров начинает расти.
                      • 0
                        Это точно. В самом начале использования Docker'a и при запуске первых версий проекта вообще никаких проблем не было. Но по мере того, как проект начал разбиваться на части, которые зависят друг от друга (вышеупомянутая микросервисная архитектура) + количество машин выросло, все стало уже не так просто и весело.

                        Пришлось потратить время, что бы вникнуть в возможные решения проблем и только потом начать их постепенно решать.
                • +1
                  Любая маленькая задумка в моей голове превращается в грандиозный план, который ограничивается только временем моей жизни.

                  Я хочу написать серию статей, про то, как сейчас у меня все устроено. Открывая занавесу тайны, там и балансировщики нагрузки и Service Discovery c DNS и распределенная файловая система и приватная сеть и т.д. Надо время, что бы разделить все это на части и сформулировать доступным для «не системных администраторов» языком.

                  То, что есть сейчас называть облачным хостингом нельзя. Но я надеюсь, что это только начало.
                  • 0
                    Вот и я надеюсь (-:
                    Потому что все статьи обычно заканчиваются установкой докера каким-либо способом… и на этом всё…
                    Так что, надеюсь, В заголовке «часть 1» — это только начало (-:
                    • 0
                      А можете намекнуть в двух словах что используется в качестве service discovery?
                      Не etcd + haproxy случайно?
                  • 0
                    Ну почему нет? У нас есть законченный пилотный проект. Конечно одним докером дело не заканчивается. Ещё как минимум нужна оркестрация (мы пока сидим целиком на ansible, но уже смотрим на kubernetes и иже с ним) и service discovery (используем consul). Сейчас докер пилит собственные решения, но судя по тому, что я видел (тот же swarm), они ещё достаточно сырые.

                    У меня пока нет статьи на эту тему, но есть слайды с выступления на ITGM.
                    • 0
                      Так напишите статью! или несколько. Многие, и я в том числе, будут признательны.
                      Нет статей, как это всё использовать в реальности.
                  • +1
                    ОК, вы сделали локальный кластер с балансировкой нагрузки. Но где тут «облачность»?
                    • 0
                      Вроде как удовлетворяет определению облачности, не? Есть конфигурируемый пул ресурсов и есть on demand интерфейс.
                      • 0
                        > вы сделали локальный кластер
                        Что вы имеете ввиду под словом «локальный»? Частный?

                        > с балансировкой нагрузки
                        Я не писал в этой части ничего о балансировке нагрузке, так что её пока нет.

                        > Но где тут «облачность»?
                        Сейчас «облачность» заключается в том, что вы можете запустить выполнение вашего веб-приложения, сказав – «Мне надо 512Mb оперативной памяти, SSD диск и MongoDB рядом. Иди выполнись там где-нибудь». И где оно будет выполняться, вы не думаете.

                        Я уже писал выше, что называть это полноценным облачным хостингом пока нельзя, предстоит написать еще несколько статей и решить массу проблем.
                        • 0
                          Что вы имеете ввиду под словом «локальный»?


                          Вот это:

                          3 сервера в одном датацентре (они должны находится как можно ближе друг к другу, что бы ping между ними был минимальный).
                      • +2
                        Не сочтите за троллинг, я сам занимаюсь виртуализацией и сервисной архитектурой. Но мой самый больной вопрос: а зачем это всё, если ресурсы железа ограничены? Вы всё равно не сможете запустить больше воркеров (инстансов?) приложения, чем допустимо в рамках суммарного железа этого кластера. Вы не сможете сказать приложению «иди и запустись где-нибудь, где есть 512Mb оперативной памяти», если этой свободной оперативной памяти не осталось на железных машинах.

                        Популярные аргументы виртуализаторов о том, что дескать «если у нас возрастёт нагрузка — мы стартуем ещё 100500 воркеров и обслужим её» разбиваются элементарным утверждением, что достаточно держать постоянно запущенными 100500 воркеров — в режиме ожидания они всё равно практически не жрут ни память, ни CPU, ни электропитание. А в случае хостинга на арендованном железе, как правило, цена за него — фиксированная независимо от нагрузки.

                        Что полезного конкретно вам дала описанная виртуализация?
                        • 0
                          Спасибо, хороший вопрос.

                          Конкретно у меня ситуация такая, что требования к размеру хранилища растут быстрее требований к CPU и оперативной памяти. Получается так, что мне надо например 4 дополнительных сервера только для того, что бы у меня было 24Tb дополнительного места, при этом 4 * 8 = 32 ядра никогда не будут загружены, большая часть из 128Gb оперативной памяти тоже будет свободна.

                          Решение, кажется, в том, что бы просто доставить жесткие диски в сервера, но выйдет дороже, чем арендовать еще несколько серверов. Каждый новый сервер идет со включенным бесплатным трафиком, который тоже используется по назначению и добавляет 1Gbps к общей пропускной способности.

                          Я уже писал выше, сколько это может стоить у AWS например. Если взять полученную стоимость, разделить на 3, накупить на эти деньги серверов, то у вас будет очень хороший запас производительности.
                          • –2
                            Но ведь писечка тут как раз в том, что можно развернуть понадобившиеся воркеры именно на чужом железе, пусть и дорого, зато очень быстро, много и строго на необходимый период, минута в минуту.
                            • +2
                              Есть ситуации, когда нагрузка сильно увеличивается (о вас написали в New York Times или ссылку ретвитнул супер известный блогер) и на ваш стартап, которому так необходима реклама наваливается огромная толпа долгожданных пользователей. И облачный хостинг как раз и должен решать эту проблему, тут вы правы.

                              Но что мы будем делать со своим стартапом, когда получим счёт от AWS на 5000$, а у вас всего столько денег на ваш проект. Возможно, было бы дешевле упасть на минут 10, пока вы оформили заказ на 4 дополнительных сервера и запустили Ansible, который их добавит в ваше облако. А оставшиеся 4900$ потратить на рекламу вашего проекта.
                              • 0
                                Вы конечно в курсе про spot и reserved инстансы в амазоне?
                                • 0
                                  Да, в курсе. Но проблему они не решают, к сожалению.
                          • 0
                            Docker Swarm пока еще в статусе «бета» и официально не рекомендуется его авторами к использованию в продакшене (хотя многие конечно же используют). А как ваш опыт с Docker Swarm? Давно ли используете, что со стабильностью, с багами? Почему вы выбрали именно его, какие еще варианты рассматривали?
                            • 0
                              Docker Swarm пока еще в статусе «бета» и официально не рекомендуется его авторами к использованию в продакшене (хотя многие конечно же используют).

                              Да, я писал в начале статьи, что использую некоторые компоненты в статусе «бета». Мой проект до сих пор в разработке и когда придет время запуска, возможно Docker Swarm уже выйдет из «беты».

                              Почему вы выбрали именно его, какие еще варианты рассматривали?

                              Изначально так получилось исторически: Сначала была одна машина и все необходимые сервисы я засунул в Docker, потом появилась вторая и я сделал тоже самое. Спустя какое-то время я познакомился с Docker Swarm и понял, что могу его без проблем внедрить у себя. C Docker'ом у меня никогда проблем не возникало (и не возникает по сей день), так что необходимости в его замене на что-то другое не было.

                              А как ваш опыт с Docker Swarm? Давно ли используете, что со стабильностью, с багами?

                              Около месяца не очень активного использование, проблем пока не встречал.
                            • –4
                              Вторая причина заключается в специфике моего проекта, он связан с приватностью персональных данных. У меня нет причин кому-то просто доверять свои данные, а своих пользователей тем-более. Меня очень волнует этот вопрос, и я обеспокоен тем, что ему уделяется так мало внимания.

                              Если бы Вы действительно переживали за сохранность ваших данных, то для вас было бы очевидно, что для того чтобы обеспечить сохранность нужно потратить денег на свой сервер, хотябы бу, поставить его в ЦОД, нанять администратора, обеспечить конфигурацию ПО согласно нужным политикам безопастности. А так это просто баловство.
                              • +1
                                Зачем вы написали глупости, на которые даже ответить толком нечего?

                                1. Где в статье хоть какая-то информация о моём проекте?
                                2. Где в статье говориться о том, что я использую для своего проекта такие же инструменты и составляющие?
                                3. Каким образом купленный сервер, поставленный в ЦОД, безопасней арендованного? К нему нет доступа у сотрудников ЦОДа или что, не пойму?

                                В общем не пишите о том, о чем понятия не имеете и все у вас будет здорово, а пока «баловство» это ваш комментарий.

                                P.S. В проекте, о котором я вскользь упомянул, используется шифрованием на стороне клиента. Так что я немного расстроюсь тогда, когда он попадет в руки сотрудников АНБ, а не сотрудника ЦОДа.
                                • –4
                                  По моему вы назвали причину для чего нужно использовать свой хостинг, цитату я привел.

                                  Может быть я Вам открою секрет, но в подавляющем большинстве при аренде сервера у провайдера, сотрудники этого провайдера имеют доступ к серверу на уровне операционной системы.

                                  Мне кажется это Вы не имеете понятие о том каким последствиям может привезти на коленке собранный хостинг по вашим рекомендациям.
                                  • +1
                                    Вы не имеете понятия о том, о чем говорите.

                                    но в подавляющем большинстве при аренде сервера у провайдера, сотрудники этого провайдера имеют доступ к серверу на уровне операционной системы.

                                    Каким образом сотрудник может «иметь доступ к серверу на уровне операционной системы» у выделенного арендованного сервера (не виртуального), на который вы сами ставите ОС? Сотрудник ЦОДа вообще ни сном ни духом что вы творите с этим бедным сервером и какие у вас там пароли.

                                    Единственное, что может сделать ваш «могущественный» сотрудник ЦОДа, это выдрать жесткий диск и попытаться примонтировать его у себя. И если ваш жесткий диск зашифрован или там просто хранятся зашифрованные копии пользовательских данных, то и это не даст ему ничего.

                                    Мне кажется это Вы не имеете понятие о том каким последствиям может привезти на коленке собранный хостинг по вашим рекомендациям.

                                    Ну расскажите мне, с техническими подробностями, к чему же это может привести?
                                    • –5
                                      А какой образ ОС вы будете ставить на сервер, не тот ли что уже подготовлен поставщиком услуг аренды сервера?

                                      Ну расскажите мне, с техническими подробностями, к чему же это может привести?

                                      Может вам еще за кофе сбегать? К Школохостерам идите они Вас всему научат, опыту наберетесь возвращайтесь поговорим.
                                      • 0
                                        А какой образ ОС вы будете ставить на сервер, не тот ли что уже подготовлен поставщиком услуг аренды сервера?

                                        А KVM и радости монтирования произвольных iso образов разве уже отменили?

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.