Когда люди запускают своей первый Docker-контейнер, они часто спрашивают: «А как мне попасть внуть контейнера?» и ответ «в лоб» на этот вопрос, конечно: «Так запустите в нём SSH-сервер и приконнектитесь!». Цель этого топика — показать, что на самом деле вам не нужен sshd внутри вашего контейнера (ну, конечно, кроме случая, когда ваш контейнер собственно и предназначен для инкапсуляции SSH-сервера).

Запустить SSH-сервер — заманчивая идея, поскольку это даёт быстрый и простой доступ «внутрь» контейнера. Все умеют пользоваться SSH-клиентами, мы делаем это каждый день, мы знакомы с доступами по паролям и по ключам, перенаправлением портов, ну и вообще доступ по SSH — хорошо знакомая вещь, точно будет работать.

Но давайте подумаем ещё.

Docker в значительной мере изменил подход к настройке серверов, поддержке и доставке приложений. Разработчики начинают задумываться о том, можно ли архитектуру их приложений разделить на более мелкие компоненты, которые будут запускаться в изолированных контейнерах, что позволит достичь большего ускорения, параллелизации исполнения и надежности. Также Docker решает важную проблему снятия облачного vendor–lock и позволяет легко мигрировать настроенные приложения между собственными серверами и облаками. Все что требуется от сервера, чтобы запустить Docker – более-менее современная ОС Linux с ядром не ниже 3.8.

В этой статье мы расскажем о том, как просто использовать Docker и какие преимущества он даст сисадмину и разработчику. Забудьте про проблемы с зависимостями, запускайте на одном сервере софт, требующий разные дистрибутивы Linux, не бойтесь «загрязнить» систему неправильными действиями. И делитесь наработками с сообществом. Docker решает множество актуальных проблем и помогает сделать IaaS гораздо более похожими на PaaS, без vendor-lock.



На облачных VPS от Infobox мы сделали готовый образ Ubuntu 14.04 с Docker. Получите бесплатную пробную версию (кнопка «Тестировать 10 дней») и начните использовать Docker прямо сейчас! Не забудьте поставить галочку «Разрешить управление ядром ОС» при создании сервера, это требуется для работы Docker. В самое ближайшее время у нас появятся и другие ОС с Docker внутри.

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

Компания Font Bureau разработала новое семейство шрифтов Input, важнейшим из которых в данном случае для нас является шрифт Input Mono. Кириллица присутствует. Для персонального использования шрифты бесплатны.

Это вторая часть моей статьи по разработке драйверов для ведомых SPI устройств в Linux. Предыдущая часть находится здесь.

3. Разработка userspace протокольного SPI драйвера с использованием spidev

Как уже было сказано выше, для SPI устройств существует ограниченная поддержка userspace API, с поддержкой базовых полудуплексных read() и write() вызовов для доступа к ведомым SPI устройствам. Используя ioctl() вызовы, можно производить полнодуплексный обмен данными с ведомым устройством, а также изменение параметров устройства.

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

0. Вместо введения

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

Для кого эта статья?
В первую очередь, для новичков, каковым являюсь и я. На форумах по embedded Linux очень часто можно встретить вопрос: «А как на этой плате работать с SPI?». Именно на него я и попытаюсь дать ответ. В качестве примера, я приведу код написанный для работы с моим тестовым SPI устройством.

Всем привет! Сегодня мы хотим предложить вашему вниманию тематический пост. Как вы знаете, сейчас в самом разгаре проходят съёмки пятого сезона «Игры престолов». Этот эпохальный сериал снимается в разных странах мира, в основном в Европе. И если вы ещё не отгуляли отпуск и являетесь преданным поклонником мира Семи Королевств, то присмотритесь к идее посетить города и места, где проходят съёмки сериала. Ведь создатели потратили немало усилий, чтобы найти уголки на планете, который дышали бы духом древности. Отчасти — нетронутости человеком. Конечно, без щедрой порции спецэффектов не обошлось, но ведь основа для большинства сцен — настоящая.

Мы подобрали для вас подборку нескольких мест проживания, расположенных в местах, где проходили съёмки сериала, либо очень похожих. Надеемся, что-то придётся вам по душе.

Не так давно в Вегасе прошли две, наверное, самые знаковые конференции в области практической информационной безопасности. Конечно же речь идет о Black Hat 2014 и Defcon 22. Доклады уже давно выложены в сети, да и хабр уже разродился несколькими публикациями по данной теме, поэтому здесь мы поговорим о подкасте Noise Security Bit #9. Этот выпуск был записан практически сразу после окончания заключительного дня конференции Defcon с русскоязычными ресечерами, а точнее с самыми стойкими из них, которых удалось отловить в момент на выходе из отеля Рио.

Предыстория: я, как и многие на Хабрахабре, чертовски люблю слушать музыку. Чаще всего делаю это в ВКонтакте. Иногда уже сфомированный плейлист надоедает — хочется чего-нибудь нового; но так, чтобы не сильно отличалось от того, что уже есть. Для этого на всех сервисах, предоставляющих возможность прослушивания музыки, существуют рекомендации. Признаюсь честно, рекомендации в ВКонтакте меня ужасают. Может кому-то нравится, но у меня тамошний подбор вызывает желание закрыть браузер (ИМХО, конечно). В общем, решил я эту ситуацию для себя исправить и реализовать свои собственные рекомендации с использованием API ВКонтакте и Last.fm. Так как я много слышал и читал про Google App Engine, но никогда его не использовал, решено было приобщиться к этой платформе.

Сразу скажу, что тонкости взаимодействия с API или алгоритм подбора рекомендаций здесь я описывать не буду. Об этом — в следующих статьях, может быть. В данной статье описан только процесс создания, настройки и деплоя приложения на платформе Google App Engine с использованием python и flask.
Об опечатках и неточностях просьба сообщать в личку. Спасибо.

В треке Service Provider у Cisco появилась новое направление — Service Provider Mobility. Предлагаются два направления — CDMA to LTE и UMTS to LTE. Для сдачи эказмена нет никаких требований, кроме как знаний самих технологий. В разделе литературы для данных экзаменов можно найти лишь PDF документ с описание курса для данной направленности. В разделе ресурсов Cisco даёт ссылки на сайт 3GPP, мануалы по настройке ASR5x00 и несколько книг разных авторов на тему мобильных сетей. Т.е. на данный момент отсутствуют специализированные книги от Cisco для подготовки к эказмену, как например для трека CCNA/CCNP/CCIE, и неизвестно, будут ли такие вообще.

Это десятая статья в серии, где я описываю свой опыт написания веб-приложения на Python с использованием микрофреймворка Flask.

Цель данного руководства — разработать довольно функциональное приложение-микроблог, которое я за полным отсутствием оригинальности решил назвать microblog.

Краткое повторение

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

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

3 августа в сабреддите /r/Anarchism некто пользователь PhineasFisher создал тред, в котором сообщил о том, что ему удалось украсть 40 гигабайт различных данных компании Gamma International. Возможно, подобная история могла оказаться не столь громкой, если бы не бизнес, которым занимается эта европейская фирма — создание и продажа программных средств для взлома и скрытой слежки (а иными словами — самой настоящей малвари), заказчиками которых обычно выступали государственные структуры. Через несколько дней после первого сообщения взломщик выложил длинный рассказ о том, как ему удалось проникнуть на сервера Gamma International и что удалось там найти.

RocksDB – постоянное хранилище «ключ-значение» для быстрых накопителей. Основное ее предназначение — хранение данных на flash дисках.

Узким местом в производительности часто является обращение к БД.
Эта проблема может решаться по разному.
Использование кэша решает проблему производительности, но существенно усложняет архитектуру программы. Графовые базы данных выходят из ситуации за счет оптимальных для данной задачи алгоритмов. Другим типом решений являются хранилища, достигающие высокой производительности за счет использования быстрого носителя.
В последнее время появилось много NoSQL хранилищ полностью хранящих данные в памяти. Но память все еще стоит дорого и ее объем ограничен. Увеличение памяти за счет шардинга опять таки упирается в стоимость.
Логичным выходом из ситуации было бы использование SSD дисков. Они имеют относительно невысокую стоимость и при этом вполне небольшое время отклика.

Всем привет!

Совсем недавно вышла публичная бета популярного симулятора сетевого оборудования GNS3 1.0. Интересен он в первую очередь тем, что стал поддерживать switching (раньше поддерживал лишь routing) с помощью Cisco IOU. Так как я пользуюсь им, начиная с альфа-версии, то решил написать небольшой гайд, как подружить GNS3 и IOU.

Дисклеймер. Cisco IOU могут использовать только сотрудники компании Cisco.

Ниже представлена инструкция и для Windows, и для Linux.

Перевод. Оригинальная статья доступна в блоге Xen.
Автор — Felipe Franciosi.

Последние тестовые сборки XenServer Creedence Alpha отличаются повышенной производительностью дисковой подсистемы по сравнению с XenServer 6.2 (подробности в блоге Маркуса Гранадо (Marcus Granado) – Performance Improvements in Creedence). В основном, улучшения связаны с внедрением новой архитектуры дисковой подсистемы — tapdisk3. Мы опишем эту технологию организации виртуального хранилища, а также приведем и объясним результаты экспериментов, в которых достигается производительность примерно 10Gb/s одним хосте с подключенным кластерным хранилищем.

Несколько месяцев назад я писал о проекте Karcygwins, который включал в себя серию экспериментов и исследований, направленных на изучение особенностей работы дискового ввода-вывода. Мы сосредоточились на случае, когда нагрузку генерирует одна ВМ с одним виртуальным диском. В частности, нас интересовало понимание природы дополнительных затрат (overhead) на виртуализацию, особенно на устройствах с малыми задержками, например — современных SSD. Сравнивая разные способы виртуализации дискового ввода-вывода, доступные пользователю (то есть blktap и blktap2), мы сумели объяснить, где и почему возникают дополнительные затраты, а также как их значительно уменьшить. Подробнее о проекте Karcygwins можно прочитать по ссылке.

С тех пор как до меня дошла благая весть о существовании операционной системы под названием GNU/Linux, которую используют все настоящие программисты, я несколько раз пытался заменить ей детище Билла Гейтса и несколько раз потерпел неудачу.

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

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

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

В большинстве случаев это было не фатально. Вместо привычного foobar всегда можно послушать музыку на Rhythmbox. Вместо Microsoft Office есть OpenOffice. Да, его совместимость с продуктом корпорации зла порой оставляет желать лучшего, но им вполне можно пользоваться для решения повседневных задач среднестатистического пользователя. Обо всяких Файрфоксах, Операх и Хромах я вообще молчу.

Но в некоторых случаях приходилось перезагружать компьютер, выбирать в меню загрузчика пункт Microsoft Windows и делать всё по старинке. Такой задачей было например снятие образа логического диска в целях переноса на другой физический носитель, потому как текущий уже изрядно поистрепался.

Пусть и с некоторым опозданием по сравнению с остальными компаниями, но Microsoft сделала необходимое и выпустила собственную нереляционную базу данных: она называется DocumentDB. И пусть это проприетарная система, которая привязана к сервису Azure, это не делает новость менее значимой.

DocumentDB автоматически индексирует содержимое всех документов, допускает обработку запросов в реальном времени, полностью поддерживает требования ACID к транзакциям (атомарность, согласованность, изолированность, надёжность). Система очень похожа на MongoDB как эффективное хранилище JSON-документов с богатыми API для запросов, в то же время выгодно отличается от MongoDB по масштабируемости и надёжности работы, глубокой интеграции JavaScript, поддержке RESTful API, асинхронных запросов и др.



Как и MongoDB, DocumentDB представляет собой иерархию баз данных, коллекций и документов.

Когда у нас появились сотрудники, работающие удаленно, пришлось думать над тем, как обеспечить им защищенный доступ к нашим хостинговым серверам, виртуальным выделенным серверам разработчиков Virtual Dedicated Server (VDS), сайтам обеспечения и сопровождения разработки и к другим ресурсам.

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

Выход нашелся довольно быстро — это использование технологии виртуальных частных сетей Virtual Private Network (VPN) и ее свободной реализации OpenVPN. Эта реализация доступна практически для всех распространенных платформ, в том числе для планшетов и смартфонов. История развития OpenVPN насчитывает уже 12 лет (компания OpenVPN Technologies, Inc. была создана Francis Dinha и James Yona в 2002 году), так что это надежное и проверенное временем решение.

В нашей компании сеть VPN позволила предоставить защищенный доступ сотрудников к VDS, играющей роль сервера OpenVPN. И уже для фиксированного IP этого сервера был разрешен доступ к другим ресурсам компании. Попутно на сервере OpenVPN был установлен прокси Squid, что решило все проблемы доступа сотрудников с динамическими IP к защищенным ресурсам компании.

Теме OpenVPN посвящены многочисленные статьи и сообщения на форумах. Тем не менее, нужную информацию мне пришлось собирать по частям из разных мест. Попутно приходилось разбираться с многочисленными терминами и технологиями. В качестве серверов OpenVPN были использованы VDS на базе FreeBSD и Debian Linux, в качестве клиентов — рабочие станции FreeBSD, Debian Linux, Ubuntu и Microsoft Windows.

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

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

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

Принципы условно сгруппированы в три группы: принципы принятия решений; принципы, направленные на повышение качества кода; принципы, направленные на повышение производительности кода.

• Принятие решений
  • Любое техническое решение должно быть обосновано
  • Ответственность за принятое решение всегда лежит на том или тех, кто принял данное решение
  • При принятии технических решений необходимо учитывать их действие во времени и их соответствие потребностям бизнеса
  • Одним из основных критериев при принятии технических и иных решений должна быть их наибольшая эффективность
  • Смело отступать от правил, методологий, шаблонов и прочих ограничений, если эффект от такого отступления превышает возможные потери (Special cases aren't special enough to break the rules, although practicality beats purity)
  • При необходимости сделать работающее, но, возможно, не наилучшее, решение сразу, а позднее улучшить его (Now is better than never, although never is often better than *right* now)
  • Если сложно выбрать между двумя альтернативными техническими решениями, то нужно выбрать любое и двигаться с ним дальше, когда появится больше инфорации, то можно будет сделать рефакторинг, если решение оказалось неоптимальным
  • Гибкость технических решений крайне желательна, а универсальность не обязательна
• Качество исходного кода
  • Качество кода следует оптимизировать на базе сформированной системы критериев, сбалансированной по отношению к затратам в краткосрочном и долгосрочном периодах
  • Писать оптимальный код сразу, если это не увеличивает его сложность и сроки разработки (Beautiful is better than ugly)
  • Самодокументируемый код имеет приоритет над хорошо прокомментированным (Beautiful is better than ugly)
  • Писать TODO и FIXME в коде
  • Давать переменным, функциям, методам, классам и другим объектам исходного кода имена точно отражающие их назначение, несмотря на увеличение длины названий (Explicit is better than implicit)
  • Меньшее число строк и объем кода предпочтительнее, при сохранении прежней читабельности кода (Simple is better than complex)
  • Применять инспекцию кода (code review) как инструмент обнаружения ошибок, выравнивания стиля разработки, знакомства с чужим кодом и обучения в команде
  • Применять повторное использование своего и чужого кода
  • Использовать специализированные библиотеки для решения конкретных задач, вместо разработки своего аналогичного кода
• Производительность
  • Производительность разработки кода имеет приоритет над производительностью исполнения кода
  • Оптимизация производительности исполнения кода должна быть обоснована соответствующей потребностью
  • Оптимизация производительности исполнения кода должна выполняться за счет устранения наиболее серьезных узких мест
  • В первую очередь должны быть использованы наиболее эффективные методы оптимизации производительности исполнения кода

Далее дано развернутое пояснение каждому из перечисленных принципов. Для некоторых принципов в круглых скобках указанны постулаты Zen of Python, которые на мой взгляд имеют отношение к данным принципам, либо их частям.

Вступление

Чуть больше года назад я сделал очень важный в своей жизни поступок — скачал с сайта Microsoft IDE Visual Studio и написал на языке C++ свою первую в жизни программу, как это ни странно — «Hello, World!». За следующие полгода я прочитал небезызвестную книжку Страуструпа, устроился на работу джуниор С++ разработчиком, попробовал писать на Lua, Python, но каких-либо значительных успехов не добился — мои библиотеки не работали, программы с трудом компилировались и падали в runtime, указатели указывали не на те участки памяти (которая, кстати, всегда куда-то утекала), а попытки использовать больше одного потока (С++11 же!) приводили к порче памяти и дедлокам. О том, как выглядел код, лучше просто промолчать.

К чему это я? К тому, что по моему личному мнению/опыту императивные языки в силу своих особенностей совершенно не подходят начинающим разработчикам. Без знаний промышленных паттернов программирования, каких-то сведений о работе операционной системы и элементарной культуры кода написать что-то сносное на них очень тяжело. Они дают слишком много свободы и пространства для костылей и велосипедов, в то время как функциональные языки жёстко ограничивая разработчика в некоторых вещах оставляют ему не так много возможностей писать плохой код, заставляя думать и развиваться.

Примерно полгода назад я понял, что пора что-то менять, и после получаса поиска в интернете нашёл спецификации ЯП Erlang. В статье автор представлял Erlang как «чудесную таблетку» от всех вышеописанных мою проблем, и в общем-то по большей части он оказался прав. Так я начал программировать на Erlang, а затем и на Elixir.

Elixir Language

Elixir — язык, построенный поверх Erlang, результат компиляции — байткод Erlang VM. От Erlang он выгодно отличается простотой синтаксиса и мощным инструментарием для мета-программирования (люди, знакомые с Lisp сразу узнают quote-unquote конструкции). Соответственно, для использования доступен весь функционал Erlang, любые его модули и, что самое главное — фреймворк OTP.

Типы данных — те же самые, что и в Erlang. Данные — неизменяемые, результат действий с ними — новые данные. В Elixir как и во многих функциональных языках работает принцип «Всё — выражение». Любое выражение вернёт значение.

У ЯП Elixir есть отличный интерпретатор, который устанавливается вместе с языком, в нём можно опробовать примеры.

Пошаговое руководство по направлению всего TCP и DNS трафика из виртуальной машины через TOR.

Тема уже поднималась в 2012 году: «Как направить весь tcp-трафик с гостевой Windows системы через Tor» с использованием tun2socks и виртуального сетевого адаптера TUN/TAP от OpenVPN.

Однако на Black Hat USA 2013 был представлен доклад «TOR… ALL-THE-THINGS!», в котором анонсировали новый инструмент от Jason Geffner из CROWDSTRIKE INC под названием Tortilla. Также Tortilla упоминается в официальном Tor FAQ в разделе What should I do if I can't set a proxy with my application?. Это виртуальный сетевой адаптер, который просто установить и использовать.