Docker в этом случае остаётся тем же, чем и был — удобным гибким инструментом для развёртывания легковесный контейнеров :) Сам по себе он не панацея ни в каком из вариантов. Это просто полезный инструмент.
NFC, LTE, 2Gb, 4 ядра, двое суток ожидания при полной синхронизации кучи софта и дней 10 при выключенной передачи данных — это мой LG G2 на стоковом Андроиде 4.2.2 :) Реально впервые за 4 года жизни с Андроидом больше не думаешь о батарейке. Кончено, реальная загрузка (музыка онлайн, книжки, видео, карты) далека от режима ожидания, но даже в таком случае заряда на рабочий день хватает спокойно там, где раньше счёт шёл на часы.
Объективно тут лимитирует только удобство ношения и удержания :) Для меня оптимум в районе 5.2", наверное. Нынешний 5.5" чуть-чуть великоват уже. В карман ещё влезает, а вот рука при долгом удержании начинает уставать.
Потому что одиночный большой палец прикладывается боком и требует очень аккуратной работы во всех случаях, кроме «попасть по половине экрана». Это напрягает и двумя руками работать легче. Ещё сильно повышается риск уронить гаджет. Особенно широкий. Какой ни будь интерфейс, но уже начиная с 4" даже страницы книжки получается перелистывать одной рукой с напряжением. А на нынешним моем 5.5" я вообще перестал листать с экрана, это реально неудобно и опасно с точки зрения удержания. Хорошо ещё, что качельку громкости догадались поставить не сбоку, а посередине сзади, это спасает :)
Вот, например, если без пайки надо, Arduino Nano 3.0. С пайкой (ножки прилагаются отдельно) можно и подешевле найти.
«Большой» Arduino стоит чуть дороже. Вот Arduino Uno r3 за $4.18.
Правда, сам именно эти позиции не заказывал. Nano заказывал дважды, но давно, ещё по ~$7..$8, недавно заказывал только Mega 2560, вот по этому лоту, сейчас — $11.70. Нормальный, сборка приличная, работает :)
>Иными словами, докер облегчает установку и развёртывание приложений, но я практически уверен что это далеко не бесплатная фишка, которая сильно усложнит дальнейшую поддержку
Вот именно эта оценка меня и отталкивала от Docker до последнего времени. Под мои задачи он не давал ничего сверх LXC, но LXC проще поддерживать, меньше лишних сущностей. Docker был прекрасен, когда нужно запустить Hello world из контейнера, для этого буквально ничего ручками не нужно делать, но когда начинается вопрос персистентности, связывания контейнеров… Тут LXC, которая по сути представляет отдельный автономный виртуальный компьютер становится проще.
Но сейчас по мере развития проектов начинаю переходить на декомпозицию и разделение функционала и тут внезапно оказывается, что плодить LXC-контейнеры во множестве и поддерживать их индивидуально становится грустно. А вот Docker, наоборот, становится привлекательнее :) Но глобальных выводов пока не делаю, на продакшне Docker'а ещё нет, только экспериментирую. Более того, на одном из основных проектов стоит CentOS, а там ядро без поддержки aufs, так что Docker в пролёте…
Я так и писал — «да, связывание только в пределах хоста».
>А я говорю о другом, когда хостов несколько
Вот для этого, как понимаю, всякие SkyDNS и предназначаются. Хотя при желании (если SkyDNS этот процесс не облегчает, как писал, я его ещё не щупал) можно и полноценный DNS настроить. Типа, контейнер запускается и сразу сообщает серверу имён свой новый IP.
>Плюс когда нужно перемещать конейнеры из одной сложной среды в другую сложную среду. И тут уже непонятно, зачем нужен докер.
Так, вроде бы Docker и имеет что-то на тему переноса контейнеров между хостами. Тоже не разбирался, мне пока хватает задач в рамках хоста, но в анонсах про CoreOS слышал, что там механизм переноса контейнеров с одного хоста кластера на другой из коробки есть. Хотя, может, это и не средствами Docker.
Связывание по --link? Да. Связывание через другие инструменты, типа SkyDNS? Полагаю, что нет, хотя на этот счёт ещё подробно не разбирался, только начинаю изучать межконтейнерное взаимодействие.
Я не минусовал, но в вопросе есть неправильная посылка. Docker не аналог CSS. В нём нельзя подменить один из базовых образов, таким образом поломав наследника. Образы Docker иммутабельны. Можно только сделать копию и поменять уже её. Но это не повлияет на наследников исходной копии.
Сейчас как раз изучаю этот вопрос. Для себя пока грубо оцениваю ситуацию так:
— Минимум вмешательства в уже работающие контейнеры. «apt-get upgrade» хорош только при формировании базового образа, но не в регулярной работе, система начнёт засоряться и бонуса по сравнению с обычным LXC не будет. Если нужна полноценная развёрнутая навороченная гостевая система, то надо сразу настраивать LXC. Это и проще будет. Docker же не для систем, а для контейнеров — узкоспецифичных обработчиков.
— Все «вмешательства» должны быть максимально автоматизированы и по отношению к контейнеру внешними. Т.е. разворачиваем базовый образ контейнера, пушим туда наш проект и в таком виде запускаем. Тут, видимо, надо смотреть в стороны локалхостовых PaaS, типа Dokku. Пока этот вопрос не изучал.
— Объёмные персистентные данные лучше, наверное, хранить не в контейнерах, а контейнерно-независимых каталогах и томах.
В таком случае обновление будет заключаться только в организации нового контейнера и запихивании туда уже настроенной задачи. Собственно, такое решение сейчас и интересует, к нему стараюсь и подвести варианты использования.
В любом случае нужно помнить, что Docker удобен именно для контейнерного подхода. Когда крупный проект декомпозирован на много мелких независимых элементов. Если требуется (или не получается провести декомпозицию) всё использовать одной кучей, то это не контейнерный подход, тут проще сидеть в виртуальных машинах «чистого» LXC. Или вообще обходиться одной гостевой системой без всякой контейнеризации. Я до последнего времени поступал именно так (ещё весной писал на форумах, что не понимаю зачем нужен Docker). Но сейчас дозрел до понимания того, что большие задачи полезно дробить на мелкие, мелкие задачи удобно раскидывать по индивидуальным контейнерам, после чего и всплывает в поле внимания Docker…
У Docker есть инструменты для связывания, например, ключик --link. Плюс в инфраструктуре Docker есть уже свои новые инструменты для облегчения связывания. Вот статья на Хабре: habrahabr.ru/post/215653/
Во! Я тоже с ~1994-го по 2012-й в руках паяльник практически не держал (хотя до 1994-го пайкой/отладкой компов и АОНов даже зарабатывал). А как про Arduino узнал, так снова начал наколенной электроникой баловаться. Дошёл до того, что недавно два десятка 7400 заказал… Хоть посмотрел на микросхему, аналог которой первым в руки взял в 1987-м… По 18 копеек в райцентре :D
>Учитывая, что в западном мире конкуренция священна, а большие корпорации принято держать в узде, то я уверен, что в суде можно было бы обязать Твиттер выдать доступ к API даже не меняя название.
Lindows, Groogle, Phoenix и далее по списку. Чаще суд выигрывает тот, у кого денег больше. Хотя исключения, конечно, тоже бывают. Особенно, когда на этом кто-то может корпорацию подоить.
А, нет. Тогда у нас всё круче было :) Я думал речь именно о фундаментальных теоретических расчётах. Просто вычислительная практика в МХТИ к моему поступлению была мощная — там был отдельный факультет кибернетики химико-технологических производств (КХТП), открытый аж в 1960-м. Но это именно прикладной уровень, т.е. расчёты производств, автоматизация управления, численные методы для обработки данных и т.п. И на нашем, инженерном физико-химическом нас начали компьютерной практикой грузить с первого же курса в 1990-м. Всякая статистическая обработка экспериментальных данных, вычислительные методы моделирования и т.п. Хотя было видно, что внедряться всё это только начинает, колбасило с программой тогда сильно. Нас учили QBasic'у на PC XT, следующий за нами курс — Turbo Pascal (тоже PC). В 1994-м на расчётах всякого хим. оборудования окунулись в Фортран на СМ-4, хотя я на сдачу зачётов волюнтаристски приносил решения на C++ :D
Весёлое было время… Забавно, что у нас со всего потока (больше сотни человек) едва ли десяток-другой пошёл работать по специальности. А вот по компьютерной части — чуть ли не половина. Из семи близких друзей один работает по специальности, один не по специальности, но в отрасли (Росатом), один и не по специальности, и не с компьютерами, двое работают с 1С (один — бухгалтер, другой — программист), один — админ, один — админ+программист. Ну и я в Web'е сейчас задержался :)
>Я пока не готов объяснять ребенку необходимость резисторов
Я просто сказал, что когда тока слишком много, то светодиоду плохо. Не помню, с чем ассоциировал перегрузку, но ребёнок понял. Умом понял, а вот привычки сперва не было :D Через минут 15 «автономного» ковыряния (я оставил без присмотра, занявшись своими делами) обращает внимание — «папа, лампочка горячая, я пальцы обожгла!». Ну, понятно — подключила без резистора. «Вот, говорю, потому и горячая, что тока слишком много. Может вообще сгореть». В течении получаса было сожжено два светодиода. Но я дал сразу россыпью, разных цветов и размеров, так что душевно в необходимости экономить ребёнок не проникся…
А вот когда ещё через час был сожжён переход у RGB-светодиода, а ещё минут через 15 второй, а я выдал RGB-светодиод только один, хотя их целая коробка (в Китае их меньше чем по 20 штук заказывать всё равно не выгодно, по деньгам почти тоже самое выходит :)), чтобы ребёнок понимал, что такое ресурсный голод… Вот после этого ни одного подключения без балластных резисторов уже не было :D
А вот соблюдение полярности на удивление с первого же раза усвоила. Перед каждым подключением «широкая ножка… ага, это минус» :)
А у нас так от моторчика отлетело куда-то крепление, на которое пропеллер надевается, да так и с концами. Теперь мотор бесполезен, на него ничего не нацепить :)
Для широкого девайса очень удобно оказалось. И удобно регулировать громкость, не доставая из кармана.
«Большой» Arduino стоит чуть дороже. Вот Arduino Uno r3 за $4.18.
Правда, сам именно эти позиции не заказывал. Nano заказывал дважды, но давно, ещё по ~$7..$8, недавно заказывал только Mega 2560, вот по этому лоту, сейчас — $11.70. Нормальный, сборка приличная, работает :)
Вот именно эта оценка меня и отталкивала от Docker до последнего времени. Под мои задачи он не давал ничего сверх LXC, но LXC проще поддерживать, меньше лишних сущностей. Docker был прекрасен, когда нужно запустить Hello world из контейнера, для этого буквально ничего ручками не нужно делать, но когда начинается вопрос персистентности, связывания контейнеров… Тут LXC, которая по сути представляет отдельный автономный виртуальный компьютер становится проще.
Но сейчас по мере развития проектов начинаю переходить на декомпозицию и разделение функционала и тут внезапно оказывается, что плодить LXC-контейнеры во множестве и поддерживать их индивидуально становится грустно. А вот Docker, наоборот, становится привлекательнее :) Но глобальных выводов пока не делаю, на продакшне Docker'а ещё нет, только экспериментирую. Более того, на одном из основных проектов стоит CentOS, а там ядро без поддержки aufs, так что Docker в пролёте…
Я так и писал — «да, связывание только в пределах хоста».
>А я говорю о другом, когда хостов несколько
Вот для этого, как понимаю, всякие SkyDNS и предназначаются. Хотя при желании (если SkyDNS этот процесс не облегчает, как писал, я его ещё не щупал) можно и полноценный DNS настроить. Типа, контейнер запускается и сразу сообщает серверу имён свой новый IP.
>Плюс когда нужно перемещать конейнеры из одной сложной среды в другую сложную среду. И тут уже непонятно, зачем нужен докер.
Так, вроде бы Docker и имеет что-то на тему переноса контейнеров между хостами. Тоже не разбирался, мне пока хватает задач в рамках хоста, но в анонсах про CoreOS слышал, что там механизм переноса контейнеров с одного хоста кластера на другой из коробки есть. Хотя, может, это и не средствами Docker.
— Минимум вмешательства в уже работающие контейнеры. «apt-get upgrade» хорош только при формировании базового образа, но не в регулярной работе, система начнёт засоряться и бонуса по сравнению с обычным LXC не будет. Если нужна полноценная развёрнутая навороченная гостевая система, то надо сразу настраивать LXC. Это и проще будет. Docker же не для систем, а для контейнеров — узкоспецифичных обработчиков.
— Все «вмешательства» должны быть максимально автоматизированы и по отношению к контейнеру внешними. Т.е. разворачиваем базовый образ контейнера, пушим туда наш проект и в таком виде запускаем. Тут, видимо, надо смотреть в стороны локалхостовых PaaS, типа Dokku. Пока этот вопрос не изучал.
— Объёмные персистентные данные лучше, наверное, хранить не в контейнерах, а контейнерно-независимых каталогах и томах.
В таком случае обновление будет заключаться только в организации нового контейнера и запихивании туда уже настроенной задачи. Собственно, такое решение сейчас и интересует, к нему стараюсь и подвести варианты использования.
В любом случае нужно помнить, что Docker удобен именно для контейнерного подхода. Когда крупный проект декомпозирован на много мелких независимых элементов. Если требуется (или не получается провести декомпозицию) всё использовать одной кучей, то это не контейнерный подход, тут проще сидеть в виртуальных машинах «чистого» LXC. Или вообще обходиться одной гостевой системой без всякой контейнеризации. Я до последнего времени поступал именно так (ещё весной писал на форумах, что не понимаю зачем нужен Docker). Но сейчас дозрел до понимания того, что большие задачи полезно дробить на мелкие, мелкие задачи удобно раскидывать по индивидуальным контейнерам, после чего и всплывает в поле внимания Docker…
--link. Плюс в инфраструктуре Docker есть уже свои новые инструменты для облегчения связывания. Вот статья на Хабре: habrahabr.ru/post/215653/Бессмертная и легендарная вещь из ХиЖ нашего поколения :D
…
updated: упс. Кристобаль Хозеевич успел раньше :)
Во! Я тоже с ~1994-го по 2012-й в руках паяльник практически не держал (хотя до 1994-го пайкой/отладкой компов и АОНов даже зарабатывал). А как про Arduino узнал, так снова начал наколенной электроникой баловаться. Дошёл до того, что недавно два десятка 7400 заказал… Хоть посмотрел на микросхему, аналог которой первым в руки взял в 1987-м… По 18 копеек в райцентре :D
И как раз свежая новость про 4.5 млн. утёкших паролей Mail.Ru.
Lindows, Groogle, Phoenix и далее по списку. Чаще суд выигрывает тот, у кого денег больше. Хотя исключения, конечно, тоже бывают. Особенно, когда на этом кто-то может корпорацию подоить.
А, нет. Тогда у нас всё круче было :) Я думал речь именно о фундаментальных теоретических расчётах. Просто вычислительная практика в МХТИ к моему поступлению была мощная — там был отдельный факультет кибернетики химико-технологических производств (КХТП), открытый аж в 1960-м. Но это именно прикладной уровень, т.е. расчёты производств, автоматизация управления, численные методы для обработки данных и т.п. И на нашем, инженерном физико-химическом нас начали компьютерной практикой грузить с первого же курса в 1990-м. Всякая статистическая обработка экспериментальных данных, вычислительные методы моделирования и т.п. Хотя было видно, что внедряться всё это только начинает, колбасило с программой тогда сильно. Нас учили QBasic'у на PC XT, следующий за нами курс — Turbo Pascal (тоже PC). В 1994-м на расчётах всякого хим. оборудования окунулись в Фортран на СМ-4, хотя я на сдачу зачётов волюнтаристски приносил решения на C++ :D
Весёлое было время… Забавно, что у нас со всего потока (больше сотни человек) едва ли десяток-другой пошёл работать по специальности. А вот по компьютерной части — чуть ли не половина. Из семи близких друзей один работает по специальности, один не по специальности, но в отрасли (Росатом), один и не по специальности, и не с компьютерами, двое работают с 1С (один — бухгалтер, другой — программист), один — админ, один — админ+программист. Ну и я в Web'е сейчас задержался :)
Я просто сказал, что когда тока слишком много, то светодиоду плохо. Не помню, с чем ассоциировал перегрузку, но ребёнок понял. Умом понял, а вот привычки сперва не было :D Через минут 15 «автономного» ковыряния (я оставил без присмотра, занявшись своими делами) обращает внимание — «папа, лампочка горячая, я пальцы обожгла!». Ну, понятно — подключила без резистора. «Вот, говорю, потому и горячая, что тока слишком много. Может вообще сгореть». В течении получаса было сожжено два светодиода. Но я дал сразу россыпью, разных цветов и размеров, так что душевно в необходимости экономить ребёнок не проникся…
А вот когда ещё через час был сожжён переход у RGB-светодиода, а ещё минут через 15 второй, а я выдал RGB-светодиод только один, хотя их целая коробка (в Китае их меньше чем по 20 штук заказывать всё равно не выгодно, по деньгам почти тоже самое выходит :)), чтобы ребёнок понимал, что такое ресурсный голод… Вот после этого ни одного подключения без балластных резисторов уже не было :D
А вот соблюдение полярности на удивление с первого же раза усвоила. Перед каждым подключением «широкая ножка… ага, это минус» :)