IT is Easy

Ресертификация CCIE по новому

Наверное все, кто обладают сертификатами Cisco, так или иначе думают о том, как поддержать свои статусы в актуальном состоянии. До недавнего времени для обладателей экспертных плашек CCIE достаточно было сдавать 1 раз в 2 года письменный экзамен CCIE written. При этом абсолютно было не важно к какому направлению CCIE этот экзамен относится. У меня самого есть с десяток сертификаций Cisco, в том числе и CCIE (Cisco Certified Internetwork Expert). И периодическая сдача written экзамена позволяла продлевать все эти сертификации. Однако все очень серьезно поменялось 24 февраля 2020 года с новой политикой ресертификации Cisco. Теперь не получится отделаться одним экзаменом CCIE Written, да и вообще Cisco убрала сам такой экзамен. Появился Core экзамен по каждому направлению. С одной стороны он выступает аналогом CCIE Written в случае первоначальной сертификации. Но вот для поддержания статуса в активном состоянии, одного такого экзамена стало недостаточно.

Сама система ресертификации у Cisco стала похоже на ту, которая используются у многих международных организаций уже давно. Теперь Cisco как и многие другие требует набора нужного количества CPE балов в каждом сертификационном цикле. Так организация ISC2, которая занимается сертификацией специалистов в области Информационной Безопасности уже давно использует систему на базе получения CPE каждый год. При этом под одним CPE подразумевается 1 час времени держателя сертификата, который был потрачен на обучение в области ИБ или аналогичную деятельность, направленную на развитие Информационной Безопасности в целом в мире. Об этом писал в статье — Сертификация в ИБ — CISSP. Сам с этим столкнулся уже давно и постоянно набираю по 40 CPE каждый год, чтобы поддерживать CISSP в актуальном состоянии. Похожие требования есть и во многих других организациях, которые поддерживают сертификацию специалистов в той или иной области. Ключевая идея в подобной системе — мотивировать сертификатодержателей постоянно поддерживать и повышать свою квалификацию.

Разворачиваем контейнеры в Kubernetes

Как работать с Kubernetes — вопрос, который волнует многих. Система оркестрации контейнеров Docker под названием Kubernetes прочно вошла в инфраструктуру серьезных приложений. Именно с помощью нее можно максимально автоматизировать процесс развертывания и обновления приложений. Родившаяся в недрах компании Google, данная система управления стала де-факто стандартом по всему миру. Да есть и другие варианты менеджмента и создания кластера работающих контейнеров Docker. Но именно Kubernetes справляется с этой задачей лучше всего. Его многие сравнивают с системой виртуализации VMware и ее системой управления vCenter. То, что делает VMware для виртуализации операционных систем, делает Kubernetes для контейнеров Docker. Как запустить нужные контейнеры в кубере и сделать их доступными снаружи кластера попробую осветить в данной статье.

Ранее в своем блоге уже не раз затрагивал тематику работы с контейнерами Docker. В частности, в статьях — Используем Docker для python приложения, Docker-сompose на практике. Как Вы понимаете с контейнерами Docker можно работать напрямую через утилиту docker, или через дополнительные различные сторонние графические интерфейсы. Но также можно задействовать и тяжелую артиллерию, каковой в данном контексте является Kubernetes. Порог входа при этом для начала использования кубера довольно высокий. Нужно не просто знать и понимать, как работают контейнеры, но также и вникнуть во множество специфичных фишек кубера. Это и поды, и ReplicaSet, и различные виды балансировки нагрузки, и многое другое. Сейчас хотелось бы не заморачиваясь во все нюансы, показать как развернуть Docker контейнер в кубере.

Google search console — почему она нужна

Всякий, кто занимается постоянно веб проектами, наверняка сталкивается с одной полезной утилитой от Google — Search Console. Также этот инструмент является жизненно необходимым в работе для специалистов по SEO. Именно с помощью него можно количественно оценить тот труд, который делают SEO-шники по продвижению веб сайта в глобальной паутине. Если Вы еще не знали об этой утилите — рекомендую внимательно к ней присмотреться. Сам буквально до недавнего времени совершенно не обращал на нее внимания. Так, только редкие упоминания друзей в беседах и небольшие заметки в Интернете. Однако со временем мой блог начал привлекать все больше пользователей из просторов Интернета с помощью поисковых систем. Это заставило более глубже познакомиться с Google Search Console. И о своих выводах, которые я сделал в процессе этого, хотелось бы поделиться в этой небольшой статье.

GitHub — наше все

Глобальный репозитарий кода GitHub стал своеобразной копилкой знаний для всех, кто связан с IT темой. В нем можно найти практически любое возможное решение проблем, относящихся к программированию и конфигурированию компьютерных систем. Философия Open Source в современном мире во много распространяется благодаря именно этому инструменту. Каждый из нас постоянно каждый день пользуется различными опенсорс продуктами. И наверняка многие задумываются о том, что, беря из «колодца», надо и отдавать что-то обратно взамен. Я с такими мыслями существую уже не один год. Если добавить к этому, что в идеале хорошо бы постоянно использовать принцип работы, при котором репозитарий Git задействуется при взаимодействии с программным кодом или конфигурациями. И тогда становится понятным, что привычка кодить с Git-ом должна быть у профессиональных ITшников на кончиках пальцев.

Кроме того в последнее время Git Hub стал своеобразным стандартом в области высоких технологий, который показывает, что тот или иной человек может сделать с IT инструментами. Зачастую на собеседованиях при приеме на работу просят показать свои репозитарии на GitHub. И то, что там содержится, может говорить гораздо больше о специалисте, чем резюме на 10 листах. Если же Вы позиционируете себя как профессиональный программист или что-то около того, то коллекция репозитариев на данном сайте просто MUST HAVE для Вас. Вообщем, хотите показать себя в современном мире IT, а также быть полезными этому миру — выкладывайте свои работы на Git Hub.

Docker-сompose на практике

Чем больше Вы работаете с Docker, тем чаще испытываете необходимость запускать одновременно сразу несколько контейнеров в связке. Это позволяет обеспечить работоспособность приложений, требующих нескольких компонентов для своего функционирования. Банальный пример, который иллюстрирует часто встречающую связку из реальной жизни — nginx, php-fpm и mysql. Как правило, современные веб приложения в минимальной конфигурации требуют СУБД — mysql, поддержку PHP, и возможность отдачи через веб сервер. Данную связку легко поднять с помощью 3 контейнеров, каждый из которых будет выполнять свой процесс. Так контейнер с nginx будет взаимодействовать с пользователями, контейнер с php-fpm обрабатываь PHP скрипты, а контейнер с mysql хранить информацию. Сами скрипты PHP и вспомогательные файлы приложения могут спокойно храниться на сервере, где работает Docker. С помощью Docker-compose проблема работы такой связки решается легко и эффективно.

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

Используем Docker для python приложения

Технология контейнеризации Docker — своеобразная священная корова последних лет в области Информационных Технологий. Именно с помощью Docker и различных систем управления для контейнеров получается реализовать самые высоконагруженные системы в мире. Также заметно упрощается процесс разработки приложений. В свое время уже писал в блоге статью из этой области — Docker в повседневной работе ITшника. Сейчас хотелось бы немного больше осветить практическую часть вопроса. А именно способ запуска python приложения в Docker контейнере на сервере. При этом подразумевается, что Вы не используете инфраструктуру наподобие Kubernetes или его аналогов, а просто хотите по мере необходимости использовать контейнеры от случая к случаю. Частенько бывает ситуация, что сервер для различных задач задействует возможности Python v2. При этом есть существенная необходимость запускать приложения, написанные на Python v3. Использование Docker позволяет элегантно решить эту задачу.

По большому счету для того, чтобы ощутить всю прелесть преимуществ использования Docker нужна хорошая система оркестрации. Именно при полной декомпозиции программных приложений под Docker с использованием систем управления мы получим отличное масштабирование, фишки CI/CD, отказоустойчивость. В данном примере всего этого у нас не будет. Мы будем разворачивать наше контейнеризированное приложение напрямую в операционной системе Linux. Это будет своеобразным примером, который позволит понять с практической точки зрения как же на самом деле работает Docker в реальной жизни.

CDN для сайта с помощью cloudflare.com

Хотелось бы рассказать о небольшом лайфхаке и возможностях, которые можно получить free of charge с помощью cloudlfare.com. Сам ресурс предоставляет услуги реверс прокси, CDN (Content Delivery Network), защиты от DOS атак и ряд других. Также cloudflare.com можно использовать как DNS сервис, и как Web Application Firewall, и ряд других сервисов. Я думаю, что многие, кто связан с темой веб разработки, прекрасно знают и используют этот ресурс. Cloudflare имеет как платные тарифные планы, так и один бесплатный тариф, который может быть очень интересен для начинающих стартапов и компаний. Даже на бесплатном тарифном плане Вы получите много фишек, которые в большинстве своем перекроют надобность маленькой начинающей компании или отдельного человека. Если же Вы перерастете нужды бесплатного аккаунта, то можете рассмотреть варианты и с платными вариантами на cloudflare.

Те, кто заинтересован в работе своих веб ресурсов так или иначе сталкивались с проблемами кеширования, различного рода внешних сетевых атак, а также обеспечения постоянной доступности сайта. И зачастую профессиональные решения CDN, защиты от DDOS атак или кеширования для таких начинающих организаций просто не по карману. Да даже и для большинства крупных организаций построить свою Content Delivery Network является крайне затратным и убыточным делом. Организовывать эффективную систему защиты от DDOS атак также не под силу большинству непрофильных компаний. Сервис cloudflare позволяет за небольшие деньги, либо вообще бесплатно профессионально решить эти проблемы.

IT инфраструктура для стартапа в Узбекистане (часть 3)

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

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

1. IT инфраструктура для стартапа в Узбекистане (часть 1).

2. IT инфраструктура для стартапа в Узбекистане (часть 2).

3. IT инфраструктура для стартапа в Узбекистане (часть 3) (данная статья).

4. Нужна ли нам облачная инфраструктура?

IT инфраструктура для стартапа в Узбекистане (часть 2)

Наступил Новый 2020 год, прошло время небольшого расслабления, которое как-то само по себе приходит на стыке лет. У меня раскачка заняла довольно таки много времени в этом году. Пришло время для концентрации и нового рывка длиною в год. В первой части статьи о том как построить IT инфраструктуру стартапу, была поднята тематика как подступиться к этой задаче людям, которые далеки от этой области. Потом была статья в блоге — Нужна ли нам облачная инфраструктура, которая рассказывала о плюсах и минусах облаков. Она была своеобразным продолжением первой статьи и затрагивала популярную тему облачных вычислений, и то, когда нужно стартапу обращаться к ним. Развивая тематику из вышеупомянутых статей, тут хотелось бы акцентировать внимание на вопросах формализации инфраструктуры, а также такого важного документа в повседневной работе ITшника, как Техническое Задание.

Необходимость документации и формализации процессов создания и работы IT инфраструктуры обусловлена сложностью и большим разнообразием компонентов. Успешность внедрения и дальнейшего функционирования во многом зависит от того, насколько все правильно расписано на бумаге. Однако, большинство организаций пренебрегает этими пунктами при своей работе. Как результат, уже при приемке сколько-то технологически сложных работ у подрядчиков начинаются постоянные трения и недовольства с ними. Заказчик думает, что исполнитель должен сделать на свое усмотрение так, чтобы все было идеально, однако в большинстве случаев исполнитель смотрит на то, что указано в Техническом Задании. И как следствие возникает конфликт ожиданий и полученного в результате. У меня до сих пор в голове периодически крутится аббревиатура из курса Cisco CCDA — PPDIOO, которая обозначает основные вехи IT проекта, и первые 3 буквы расшифровываются как Prepare (Подготовка), Plan (Планирование) и Design (Дизайн). Именно с этого должен начинаться любой IT проект.

Нужна ли нам облачная инфраструктура?

Данная статья является логическим продолжением — «IT инфраструктура для стартапа в Узбекистане». В той статье мы остановились на основных проблемах, которые возникают у начинающих стартапов при создании собственной IT инфраструктуры своей компании. Здесь хотелось бы поделиться своим опытом и мыслями о том, когда стоит использовать облачную инфраструктуру, а когда нет. О плюсах и минусах облаков. А также о нюансах и специфике, про которые стоит задуматься перед тем, как начать использовать в реальной практике. Облачные технологии, пожалуй поднимают планку необходимой экспертизы и интеллектуальных навыков инженеров на еще более высокий уровень. По сути в таких проектах, основными затратами организации становятся покупка ресурсов публичного облака и оплата труда инженеров, поддерживающих и работающих с этой инфраструктурой.

Давайте представим, что Вы находитесь у истоков какого-либо проекта, который требует серьезных вычислительных ресурсов. У Вас на сегодняшний момент будет два различных пути организации IT инфраструктуры. Первый и наиболее апробированный большей частью организацией — строить свой ЦОД или определенную серверную комнату со всем необходимым пассивным или активным оборудованием. Данное оборудование и будет выступать ядром IT инфраструктуры. Второй путь, который стал очень популярным за последние несколько лет — использование облачной инфраструктуры публичных провайдеров, таких как Amazon AWS, Google GCP, Microsoft Azure и т.д. По всему миру за основными лидерами в облачных технологиях подтягиваются и многие другие компании. Однако, тон задает именно эта троица и в первую очередь AWS.