Александр Ме

как я понял по ответам тут собрались адепты докера. В этой церкви последователь должен появиться атеист. Только сегодня был большой срач насчет какие проблемы можно получить при переходе на докер https://habrahabr.ru/post/332450/ очень советую почитать.

Теперь к вашему вопросу. Докер НЕЛЬЗЯ использовать для персистентный образов. Т.к. если его правильно готовить никакой уверенности нет на какой ноде будет запускаться ваш контейнер физический. Т.е. все что пишет в память или на диск нельзя оборачивать в докер контейнер. Потом есть системы оркестрации, которые ваш контейнер могут с одной ноды на другую перебросить, что вы думаете будет с памятью контейнера - правильно, она очистится.

Тут мне могут возразить что у нас все работает на "отлично" - это вы господа с проблемами не сталкивались. Читаем статью по ссылке выше и начинаем готовиться.

Давайте разберем ваш стек и посмотрим что можно упаковать в докер контейнер.
- NodeJS - не знаю как это у вас работает, если нет состояния - то можно
- MongoDB - база, пишет в файлы, однозначно нельзя
- ElasticSearch - этого зверя точно нельзя он и в память и на диск пишет
- Redis - пишет в память, точно нельзя

И что в итоге вы хотите обернуть в контейнер? И зачем вам докер? Чтоб mongodb была запущена от имени root? При этом мы помним о проблемах с безопасностью самой mongodb. Или elasticsearch завернуть в докер, он физический сервер способен утилизировать на 100% по памяти, пропускной способности дисковой подсистемы и 100% процессорного времени, а вы ему хотите еще один уровень абстракции в лице докера? ))

Одно дело на компьютере разработчика использовать docker-composer и совсем другое дело в продакшене.

https://jsfiddle.net/osqhbox4/

Докер применяют по разному но основное применение - средство деплоя аля deb, rpm.
Вы вполне можете обойтись без него. Мало того, ненужно пихать докер повсюду это контр продуктивно.

Представьте что нет никакой ложки докера.

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

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

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

В норме клики будут получены тем слоем, который выше. Но вы можете прописать ему pointer-events: none и он пропустит клики на более низкий слой.
positivecrash.com/pointer-events_css

ставишь блок с соц сетями на это место абсолютом к примеру. даешь блоку opacity: 0;
при ховере даешь opacity: 1;
или visibility: hidden; и visibility: visible;

SLIM:

.main
      .child
      .child
      .child
      .child
      .child

CSS:

.main {
  background-color: #e1e1e1;
  width: 100%;
  display: flex;
  flex-direction: row;
  flex-wrap: wrap;
  justify-content: center;
}

.child {
  margin: 5px;
  background-color: green;
  height: 20px;
  width: 30%;
}

Результат:

Вероятно у кнопки display: inline-block. Дайте ей display: block и все схлопнется.

Обратиться к родителю по средствам css, к сожалению, никак нельзя.

Стоит. Каждой задаче свой инструмент. Если ангуляр и реакт вошли в моду, это не значит, что способы упрощённой манипуляции домом из неё вышли. Если тебе кто-то говорит, что jQuery - костыль для людей, не умеющих нативно перебирать ноды или писать xmlhttprequest - скажи им, что компьютер - это костыль для людей, не умеющих жить без гугла и социалок. jQuery всегда будет популярен. Он упрощает простые обмены данных, классов в пределах DOM, умеет работать с ajax и значительно упрощает синтаксис.

Не совсем нарушает, если быть точным. По хорошему, WordPress ведь идет с лицензией GPL, которая в свою очередь требует чтобы все, что использует WP также наследовало лицензию GPL, даже если вы берете деньги за свой продукт. А GPL сама по себе позволяет делать с продуктом что угодно.

Но в реальности там черт ногу сломит. К примеру, есть бесплатный WP Sync DB. Ребята из Delicious Brains разработали платный плагин WP Migrate DB Pro, а потом кто-то его купил и выложил бесплатно. Потому что лицензия позволяет. Это конечно дико выбесило ребят из Delicious Brains (оно и понятно), но юридически им не удалось что-то сделать. К тому же, этот интересный человек внес в плагин некоторые изменения, и это уже стало деривативом. Вот такой казус.