Vaavaan

К юристам и бухгалтерам на форум.
При чем здесь технический форум?

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

Свифт - это прежде всего Apple-овская платформа поддерживается. Остальные - туго. Перспективен для смартфонов iOS.
Go - это прежде всего веб и утилиты (Docker, например, на Go). Смартфоны Go умеет, но как вспомогательный.

1. На Python CMS практические нет. Исторически сложилось, что весь выбор CMS - исключительно на PHP.
2. Знания языка программирования, при использовании готовой CMS уже заточенной под задачу, не требуется.
3. Брать сразу движок интернет-магазина нужно. А не универсальную CMS.
4. На Python имеет смысл на фреймворке, а не на CMS. Pyramid, Django и пр.

Например
https://habrahabr.ru/post/229375/

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

CMS Dolphin, Joomlasoc
Но вообще

национальной социальной сети.

в таких масштабах это точно не CMS.
и это даже не на фреймворках без CMS.

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

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

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

https://habrahabr.ru/company/hexlet/blog/258815/

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

Обычное женское поведение.
Все нормально.

Я прифигел от подобной наглости мадам, пошел выпил стаканчик воды и вроде отпустило. И с этого дня началось: по несколько писем в день на почту с пометкой "URGENT!!!", полный игнор моих писем и каждый день новые требования выполнить все немедленно. Я понимаю, клиент всегда прав, но тут просто атас.

Клиент всегда прав?
Отнюдь.
Всегда правый клиент заставит тебя сесть на велосипед и крутить колеса чтобы электрогенератор вырабатывал энергию для его VDS.

А теперь давайте посмотрим с ее стороны:

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

И вот сайт лежит.

Кто виноват?

Вы виноваты.

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

Дискокачалка.

Любая сделка - это договоренность между покупателем и продавцом. Индивидуальная.

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

Проекты под монетизацию продаются, как уже написали, исходя из предполагаемого дохода.

Правда 2 года - это странная оценка. Если проект очень рисковый и может быть вскоре безвозвратно прикрыт/потерян, то счет идет на месяцы.

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

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

Сможешь убедить? Молодец. Возьми с полки миллион.

Не сможешь? Хочешь 10 000 рублей?

Сайт получает деньги только за разовую регистрацию пользователя?
Регистрируй с телефоном

И чтобы использовать скидку, человек должен будет получить СМС (и сказать его содержимое тому человеку которые ему физически предоставляет скидку).

На самом деле - это хорошо, что передают аккаунт. Это значит начал работать сарафан.

Объявню как для маленького (хотя там и не так, но принцип ты поймешь) -
16 Г требуют 160 проводков.
32 Г подключаются по 168 проводкам.
В твоем компьютере - только 160.
Восьми не хватает.
Не будет работать.

Если у вас сервера куда вы хотите устанавливать софт работают под определенным дистрибутивом (например Ubuntu), то, скорее всего, вы перед внедрением окончательное тестирование и подготовку к развертыванию будете делать на машине с аналогичным дистрибутивом (или на виртуалке).

Чего это?
Вы же про Докер пишете. Не надо с ним этого.
Можешь хоть под Window сидеть хоть под MacOSX хоть под RedHat
Внутри Докера у тебя будет то, что нужно.

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

Слазите в исходники ядра и посмотрите. Там несколько десятков ассебмлерных команд это "затормаживают". Подсказать сколько в секунду таких команд на процессоре 2,5 ГГц или сами догадаетесь?

Собирать контейнер нужно на том, который тебе нужен для работы.
Идея контейнеров в том, что тебе плевать на то, что снаружи контейнера.

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

Сервер не выполняет одну функцию с этой точки зрения.
Там есть контрольные сервисы - в своем контейнере.
Там есть основных парочка минимум - для надежности и зелено-голубого деплоя.
Там есть балансировщик между этими двумя.
И это по минимуму.

А сейчас пошла тенденция - сервисы автоматически размещаются по серверам, максимально уплотняя. Нет никакой гарантии что на этом железе будет работать 1 большой или 20 маленьких сервисов и что это сохранится после перезагрузки сервера.

Зачем ставить другую ОС? Как правило не ставят. В конейнере всегда одна. Но если захотят - поставят другую. И благодаря контейнерам ты этого и не заметишь.
Очередная ОС займет всего то +50 мегабайтов.

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

Некоторые зависимости противоречивы. Нельзя одновременно поставить. На голую ОС.
А в разные контейнеры - можно.

Идеология Докера - собирать образ.

Если у вас заранее собраны образы
до сих пор: ubuntu > ruby-2.3.0 >
и вот этот: ubuntu > ruby-2.3.1 >

то сделать оставшееся
> nginx-passener > app
Докер сможет очень быстро.

Что значит, тащить данные из Volume.
Переподключите.

https://habrahabr.ru/company/hexlet/blog/258815/

Для разработки, тем более в Windows нужен не Docker, а Vagrant.

Вход по SSH только по ключу. Не по паролю.
Изоляция приложений в отдельных контейнерах. Всех приложений. Как правило 1 приложение 1 контейнер. Ну в крайнем случае - chroot на каждый сайт.
Открыть на файрволе только необходимые порты (как правило 22, 80, 443 и все).

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

бэкапы ежедневно.

Все изменяемые данные, например картинки, ccs, js

Это неизменяемые части приложения. Они должны располагаться внутри Докеровского образа. Каждый раз при изменении css - образ перестраивается. Поскольку он инкрементальный - это быстро и не тратит много место на диске.

и загруженные пользователями файлы хранить в volume образе.

Не обязательно как файлы.

Можешь загружаемые пользователем файлы класть по сети на S3 или OpenStack Swift хранилище. Есть софт - эти вещи можно взвести и локально. А можно использовать и внешние серверы. Например, с помощью Ceph Object Storage.

Скажем Ceph автоматически размазывает данные на несколько серверов (полубэкап получается).

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

Kubernetes, Yandex Cocaine (cocaine-runtime, cocaine-plugins, cocaine-tool)+Yandex Elliptics, Nomad+Consul+Registrator+Prometheus+Grafana, CloudFoundary, OpenShift, OpenStack, CoreOS, Docker Swarm, EtcD, Fleet, GoCircuit, Helios, AWS ECS, HTCondor, Hadoop YARN, Nagios/Zabbix/Sensu, SkyDNS, SmartStack, Puppet, Ansible, Chef, doozerd, CloudFormation, Boto, Fog, Heat и пр.

Что то из выше перечисленного - законченные платформы, что то кусочки из которых можете сложить свою платформу.

Rancher не сырой. Сырая RancherOS. Можно использовать другую.

Mesos вы использовали голый что ли? К нему нужна Aurora, Maraphon, Singularity.

Они все заточены под дикое количество нод. Ничто не мешает использовать и на 5 нодах. Правда, к примеру, Mesos из-за его Zookeeper неоправдано хочет минимум 16 гигабайтов на ноду.

В принципе достаточно Consul для многих вещей.
Пример:
https://medium.com/@ladislavGazo/easy-routing-and-...