• Что нужно знать чтобы стать начинающим системным инженером (devops)?

    Singaporian
    @Singaporian
    Статья, которую должен прочитать каждый.

    DevOps - не профессия. Это название культуры доставки кода от разработчика (dev) через тестировщиков и до сисадмина(ops) и обратная связь по этой цепочке.

    Человека, который внедряет DevOps, обычно называют... как хотят. Чаще всего этим занимается какой-нибудь нон-конформист в команде.

    Профессии, которые отрисуются в процессе построения этой методологии следующие:
    • Build Engineer - инженер, который управляет зависимостями, сборками, конфликтами кода.
    • Release Engineer - инженер, который управляет репозиторием кода (кто куда и по каким правилам мерджится и откуда бренчуется). Пожалуй, это самая сложная задача в больших проектах. Особенно с нестрогим Agile или в Waterfall.
    • Automation Engineer - инженер, который занимается автоматизацией рутинных задач. Обычно деплоймент, автотесты, etc. Все эти buzz-слова типа Docker - его инструментарий.
    • Site Reliability Engineer - инженер, который поддерживает ops (апгрейды, расширение железа)
    • Configuration Manager - непонятная мне специальность. Жуткое порождение HR-специалистов, давящих на громкое название позиции. Можно было бы пойти дальше и назвать специальность ZooKeeper Vice President

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

    Почти всегда все эти роли совмещают один-два человека. Ну это зависит от качества кода.
    Назовем эту компанию BRAE/CM для краткости.
    Задача BRAE/CM состоит в том, чтобы программный код, который выходит из под пера программистов, оставался на контроле программистов и сисадминов одновременно. Программисты, равно как и сисадмины, благодаря DevOps-подходу, имеют возможность и даже обязаны обслуживать код на протяжении всего жизненного цикла от планирования архитектуры до мусорки.
    То есть сисадмины начинают рулить еще до того, как код попадет к ним - на ранних стадиях, а программисты продолжают рулить своими задачами уже после того, как код от них ушел к сисадминам - на поздних стадиях. И все это прозрачно друг для друга и все проблемы и решения ходят туда сюда и не спотыкаются о бюрократия в стиле "ничего не знаю, мы код уже закоммитили, у меня тут свои проблемы, у них сломалось - пусть сами и чинят".

    Так вот эта работа - завершающая стадия системного администратора и начинающая стадия разработчика. Поэтому не бывает Junior BRAE/CM.
    BRAE/CM бывает всегда только Senior в системном администрировании и всегда Junior в программировании.

    Еще один момент. В домашних условиях можно выучить инструменты на базовом уровне. Но не поварившись в одной кастрюле с реальными разработчиками, смысл всей этой кухни не понять. Так что сразу забейте. Но если хотите, могу описать пошаговый длинный путь как стать RE/CM:

    Сразу оговорюсь по языкам.
    У каждого языка свое предназначение. Java чаще используется в корпоративном секторе. Там много серверов и сложные бизнес-приложения. Поэтому Java-мир очень чувствителен к таким понятиям, как "технинческий долг" и "управление процессом разработки". И именно поэтому именно там все основные вакансии DevOps и именно там будет самый интересный опыт.
    Кроме Java, традиционно сильная DevOps-культура у Ruby. Практически все остальные языки не имеют столь развитой и популярной инфраструктуры в в данном контексте и потому вам скорее всего будут неинтересны.
    Другими словами, если в среде разработчиков выбор языка - тема для холивара и эмоций с миллионами сравнительных анализов с противоположными результатами, то для специалистов по DevOps выбор очевиден и прозрачен. Java - это одновременно самые интересные задачи, самый богатый toolset, самый большой выбор вакансий и самые высокие зарплаты.

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

    Итак, что делать:
    1) Почитать книги Head First по Java. Пройти курсы Java на EDX.
    2) Освоить SVN. Есть прекрасные тьюториалы. (GIT освоим позже)
    3) Поставить VirtualBox (не VMWare!!!)
    4) Написать простенькое приложение. Код коммитить в SVN. Собирать его при помощи maven.
    5) Поднять на отдельной виртуалке Jenkins. Он должен брать код приложения на SVN и запускать свой локальный maven для сборки.
    6) Написать модульные тесты (unit tests) своего кода. Пусть maven и их прогоняет.
    7) Поднять где-нибудь Nexus. Усложнить задачу maven, чтобы он теперь складывал все в Nexus. Если maven'у потребуются внешние библиотеки, он тоже не сам должен ходить в интернет, а через Nexus (Central repo).
    8) Настроить на своем десктопе vagrant так, чтобы он с нуля создавал виртуалки VirtualBox.
    9) Создать виртуалку DEV через vagrant. При этом ansible должен на ней что-нибудь настроить (например установить JDK)
    10) Научиться деплоить jar/war из Nexus на виртуалку DEV чем-нибудь. Чем - не посоветую, так как сам работаю с очень сложным IBM uDeploy, а это точно не для новичка. Посмотрите в сторону Rundeck или чего-то такого. Может самим Jenkins'ом задеплойте.
    11) Напишите интеграционные АВТОтесты. На чем хотите (как вариант: Selenium).

    Усложняем систему.
    12) Донастраиваем Jenkins: собирает maven-проект; выкладывает на Nexus; дергает vagrant/ansible для создания виртуалки SIT (system integration test); деплоит приложение на SIT; прогоняет автотесты на SIT; удаляет виртуалку после успешного завершения автотестов.
    13) Прикручиваем SonarQube в Jenkins для статического анализа кода. Исправляем косяки своего кода, согласно полученным от SQ рекомендациям.
    14) Прикручиваем мониторинг Sensu.
    15) Пишем нагрузочные тесты на чем-нибудь. В идеале потрогать два инструмента: jMeter и Gatling.
    16) Как и в 12-м шаге прикручиваем в Jenkins автоматизацию создания виртуалки SLT (Stress/Load test) и прогона на ней тестов. Только уже лоад-тестов(обязательно) и стресс-тестов(опционально) соответственно.
    17) Дописываем в свое приложение какой-нибудь функционал, чтобы использовалась база.
    18) Придется познакомиться с LiquiBase. Деплой SQL руками делать запрещено.
    19) Перейти на Docker (то есть теперь приложение выкладывать не напрямую в ОС, а внутрь докера)

    20) Денек на то, чтобы почитать про Agile, Scrum, Waterfall и прочие организационные порядки.

    А теперь немного уходим в управление проектом:
    21) Поставить Atlassian Jira. Разобраться, чем отличаются Epic, Story, Task, Sub-Task. Создать себе подобной этой структуре фронт работ (делать его не придется, просто нафантазируйте).
    22) Поставить Atlassian Stash и связать его с Jira.
    23) Переехать со своего SVN на GIT, предоставленный Stash'ем.
    24) Пройти Git-тьюториал какой-нибудь. Инструмент очень нетривиальный.
    25) Взять любую таску в работу. При этом в начале работы сделать новый Git branch из тикета Jira.
    26) По завершению работы запустить всю построенную ранее цепочку, но уже для своего брэнча.
    Дайте попробую угадать: вам пришлось скопировать все джобы и переписывать в них ветки?
    27) Сделать джобы нормально. Чтобы одни и те же можно было использовать для любых веток - по аналогии с принципом программирования "reuse code". У Вас будет reuse job :)
    28) Сделать pull request, самому сделать code review и самому себя же за-approve'ить. После этого сделать merge своей ветки в master.
    29) Сделать сборку брэнча автоматической по git-hook (или SCM pool)

    30) А теперь высший пилотаж: к чертям Docker, Copistrano и прочую buzz-word-hipsters-галиматью. Теперь вы с этим знакомы и сможете применить, но пришло время выгрызать этот детский сад калёным железом. Теперь вы доставляете код только как .deb-пакеты. Это значит, что вы:
    a) разбиваете control-файл на несколько пакетов, возможно с lib*,
    b) оверрайдите все ~20 dh_ в файле rules так, чтобы все это соответствовало вашим наработкам в предыдущих пунктах.
    c) раскидываете файлы по .install
    d) самое тяжелое: готовите .preinst, .postinst, .prerm, .postrm файлы СОГЛАСНО ИХ ПРИМЕРАМ .ex, сгенерированным dh_make - то есть с разбиемнием на update/configure/broken-install и что там еще есть. Это означает, что при переустановке, при апгрейде, при даунгрейде, при удалении и при пурдже, у вас будут разные сценарии, каждый из которых должен быть проработан досканально. На этом этапе вы также познакомитесь с понятием "регрессионные тесты".

    Ну как бы базовый вариант вот. Но это далеко не весь инструментарий и путь. Это так, для начала.
    Кроме этого неплохо бы познакомиться с Puppet (это не очень подходит для DevOps, скорее для рядовых админов с кучей серверов, но это очень популярный инструмент ввиду того, что никто не понимает, что такое DevOps и вас скорее всего заставят управлять сотней серверов, вместо релиз инжиниринга). А так же нужно познакомиться с операционными системами NixOS (обязательно) и CentOS/Debian (опционально, но я бы палкой бил тех, кто не знает эти OS). Кроме того, надо базово ориентирваться в PostgreSQL.

    Внимание, важный момент, который должен быть вшит на уровень подсознания у DevOps-ориентированного инженера: вы все время пробуете новые инструменты. Вы всегда будете находить что-то очень отличное. Знаете Nexus как свои пять пальцев и он решает почти все проблемы? Отлично! Теперь выкидываете Nexus и ставите Artifactory. Знаете хорошо CentOS? Круто! Теперь пробуете все это проделать на Windows или Debian. Потому что только когда вы сможете сравнивать инструменты, ваша работа будет ювелирной. А DevOps бывает либо ювелирным, либо он не DevOps. Вы должны быть языко-независимым, платформо-независимым и инструменто-независимым.

    Что будет дальше? Дальше вы начнете работать с микросервисами (сотни одинаковых контейнеров в облаке, которые должны как-то работать друг с другом без ручной конфигурации). Тогда познакомитесь со всякими Consul, ZooKepper и кучей инструментов AWS/OpenStack.
    Ответ написан
  • Счего начать изучение DevOps?

    @yellowmew
    Cloud infrastructure, monitoring engineer. SRE
    Saboteur неплохо ответил(что не отменяет того что все остальные ответившие тоже правы)
    Девопс - это практики. Это не набор инструментов( инструменты используются на определенных этапах, реализация которых необходима для приближения к идеалу), однако определенные необходимые инструменты опять же есть.
    Про девопс можно прочитать очень много информации, но я, как админ (win-админ :D) вижу ситуацию для вас, как и любого, с опсовой основой, примерно так:
    1. Жирным вы выделили вопросы который для вас вот конкретно сейчас не играют ни малейшей роли. Дмитрий Шицков и Saboteur написали почему: зависит от проекта.
    2. Завет любого ops-а: автоматизируй всё что можно
      Если выбор между configuration management (chef, ansible, puppet и тд) и скриптами - то лучше первое. Хотя и тут можно поспорить, у меня в проекте chef-ом автоматизированное не очень-то используется на последнем этапе доставки в прод, поскольку мы все равно запечатываем машину и запускаем в AWS с asg без пост-конфигурации. Тут можно до посинения спорить хорошо это или нет, но скрипты в идеальном мире проигрывают DSL
    3. Вы пишете код для автоматизации
      Вам понадобится git (который тянет за собой git-хостинг: bitbucket, github, gitlab и тп.) и навыки правильной работы с гитом. Для отслеживания и планирования изменений - понадобится какой-нибудь таск трекер (jira, таск трекер встроенный в gitlab, что-то другое).
    4. Инфраструктура как код
      Автоматизируй всё означает автоматизацию развертывания инфраструктуры
      Здесь уже вступают в силу особенности вашего окружения - в облаках вы скорее всего захочете использовать terraform или, например, CloudFormation в AWS - встроенное средство оркестрации, или же будете сразу все запускать в контейнерах - docker , kubernetes используя соответствующие инструменты.
    5. Мониторинг
      Без правильного и подходящего вашему продукту мониторинга(+логирования) жить нельзя. И это было еще до DevOps тренда - это классика администрирования. Здесь ничего не посоветую, с Zabbix-ом сам не ужился, переехал на influx и прилегающие (TICK stack). Для логирования - graylog, ELK. В некоторых частях используется prometheus который в том числе и для кубера удобен. В общем - с чем подружитесь.


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

    Для примерного осознания всего цикла можно посмотреть на (картинка относительно рандомная,таких много, два года назад я ориентировался по другой, с более подходящим мне списком инструментов, но найти не могу =( )
    Slide1.jpeg

    P.S. Еще раз хочу отметить что описанное выше основано на личном опыте и это - движение в devops со стороны ops. Есть те, кто сразу пытаются строить все по девопсу параллельно обучаясь опсовой части и девелоперской( видел таких, не у всех получалось ). Есть те, кто двигается в девопс со стороны Dev. Все будут иметь разные мнения что важно для того, чтобы начать
    Ответ написан
  • Перенос MS DC из одного esxi в другой esxi?

    Berezoff
    @Berezoff
    Сисадмин-виндузятник, немного линуксятник
    Итак если я все правильно понял вам надо перенести ВМ с контроллером домена в другой офис по существующему каналу VPN. Мне видеться два пути:
    1. Перенести ВМ при помощи встроенного в vCenter механизма vMoution
    2. Перенести при помощи Veeam - там есть схожий механизм Quick Migration
    Еще пару замечаний
    1. Все работы лучше проводить во вне рабочее для вашей конторы время и предварительно сделав БЭКАПЫ
    2. Перенос ВМ контроллера домена лучше совершать в выключенном состоянии.
    Ответ написан
  • Какой командлет использовать для удаленной смены статических IP win 2008r2?

    @yellowmew
    Cloud infrastructure, monitoring engineer. SRE
    $NetAdapter = Get-NetAdapter -Name $InetrfaceName
    $NetAdapter | New-NetIPAddress -IPAddress $IP1 -PrefixLength $NewNetMask
    $NetAdapter | Remove-NetIPAddress -IPAddress $IP2 -PrefixLength $NewNetMask -Confirm:$false
    $NetAdapter | Set-NetRoute -NextHop $NewGateway
    $NetAdapter | Set-DnsClientServerAddress -ServerAddresses $NewDNS1,$NewDNS2

    https://technet.microsoft.com/en-us/library/jj1308...
    Обратите внимание, что командлеты работы с сетью зачастую доступны только, начиная с windows 8\server 2012
    По приведенной ссылке на technet, например, видно, что get-netadapter доступен начиная с 8.1\2012 R2

    Для реализации вашего функционала в windows 7\server 2008 нужно или использовать netsh (пусть и в powershell скрипте) или через wmi
    Ответ написан
  • Есть ли альтернатива отключению админских шар (C$ и прочие)?

    @1qaz2wsx3edc
    Active Directory admin
    Не буду никого критиковать, но большинство ответов мягко говоря странны на мой взгляд. Советовать что-то отключать \ фаерволить не имея полной доступной информации об IT ландшафте организации достаточно самонадеянно. Более всего мне близок ответ Сергея Ковалёва. Дополню обсуждение своими мыслями - на мой взгляд в данном кейсе можно выделить несколько проблем.

    1) Проблема расположения sensitive данных.

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

    2) Распределение задач внутри IT отдела, настройка ролевого управления.

    Если каждому системному администратору (вплоть до новичка) выдавать доменного админа, то рано или поздно можно нарваться на неприятности. Я думаю это сильно недооцененный риск, особенно на малых (до 500 человек) предприятиях (где и ИБ службы то толком нет). Считаю, что следует потратить какое-то разумное время и настроить доступа через группы (например - администраторы файловых серверов, администраторы почтовой системы, администраторы групповой политики, администраторы компьютеров Scope-A, администраторы компьютеров Scope-B. Так же необходимо произвести аудит объектов и разрешений на них в самой AD и тонко настроить тоже через группы. Единожды вложившись (в зависимости от инфраструктуры предполагаю от 3 дней до нескольких недель) вы оградите себя от массы геморроя в будущем.

    3) Я бы поставил пунктом #1 на самом деле. Судя по всему (сужу по фразе "руководство обеспокоилось тем, что администраторы домена имеют неограниченный доступ на их рабочие станции (боятся за свои файлы) и приказало отключить админские шары." налицо полное непонимание бизнесом роли IT службы в функционировании собственно этого самого бизнеса. Я бы постарался наладить некий диалог и донести ваше видение проблематики IT на предприятии до наемного менеджера \ собственника бизнеса.
    Ответ написан
  • Есть ли альтернатива отключению админских шар (C$ и прочие)?

    athacker
    @athacker
    Службу "Сервер" поотключайте на рабочих станциях. Рабочие станции ничего расшаривать не должны, если по уму. Соответственно, служба "Сервер" им не нужна.
    Когда админу будет надо -- он может поднять удалённо эту службу, и сделать, что ему нужно :-)

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

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

    @solalex
    Адрес шлюза, выдаваемый по DHCP и есть адрес роутера. Что касается веб-морды, то ее могли перенести на другой порт, не 80 как по умолчанию. Можно запустить сканер портов и найти порт админки.
    Ответ написан
  • Как автоматический копировать/перемещать файлы?

    @yellowmew
    Cloud infrastructure, monitoring engineer. SRE
    Абсолютно бесплатный PowerShell умеет мониторить содержимое папки.
    Можно взять за основу скрипт , прописать нужные пути, и в блоки с -SourceIdentifier FileCreated и -SourceIdentifier FileChanged вставить switch типа
    $a=Get-Item ($folder+"\/"+$name)
    switch ($a.Extension)
    {
    '.mp3' {Write-Host "AudioFile"; Copy-Item $a.FullName -Destination d:\test\Audio}
    '.txt' {Write-Host "TextFile"; Copy-Item $a.FullName -Destination d:\test\Text}
    '.bat' {Write-Host "batchfile"}
    }
    Ответ написан
  • Быстро ли можно освоить базовые скрипты powershell?

    Нагуглил то с чего сам быстро вникал.
    1) https://www.youtube.com/watch?v=kJB6IF3p9vE&list=P...
    2) https://www.youtube.com/watch?v=hVzXH0DfvWI

    Этого хватит что бы за 1 день освоить принцип работы PowerShell.
    Далее практика и конкретные задачи.

    Есть особенности про которые не все знают, надо гуглить, например можно написать класс на чистом C# и использовать его в скрипте как дополнительный тип.
    Например:
    Add-Type @'
        public class Employee
        {
            public string LoginName { get; set; }
            ...
            public string Name { get; set; }
            public System.Collections.ArrayList blablabla = new System.Collections.ArrayList();
    
            public override int GetHashCode()
            {
                return LoginName.GetHashCode();
            }
    
            public override bool Equals( object obj )
            {
                if ( obj == null )
                {
                    return false;
                }
    
                Employee p = obj as Employee;
                if ( ( System.Object ) p == null )
                {
                    return false;
                }
    
                return ( this.LoginName == p.LoginName );
            }
    
            public override string ToString()
            {
                return this.LoginName;
            }
        }
    '@
    Ответ написан
  • Выполнение скрипта раз в 5 секунд Linux

    @inkvizitor68sl
    Linux-сисадмин с 8 летним стажем.
    Вообще для этого есть snaked.

    Но если уж городить костыли, то:
    #!/bin/bash
    while :; do sleep 5; flock -n /tmp/lock1 -c /var/script.sh & done


    Эта конструкция будет запускать скрипт примерно каждые 5.04 секунды (помимо пяти секунд ещё будет тратиться время на вызов sleep и execve скрипта). При том само время работы скрипта уже не будет влиять на "каждые 5 секунд". Flock здесь нужен на тот случай, если скрипт "залипнет" - чтобы не плодить много запущенных копий скрипта в системе. Если скрипт ходит куда-то наружу или в базу - обязательно используйте flock.

    Дальше нужно обеспечить надежный запуск самого цикла. Тут уже на помощь придет cron (вместе с flock). Добавляйте в /etc/crontab такую строку:
    * * * * * root flock -n /tmp/lock2 -c /path/to/script2

    Каждую минуту крон будет пытаться запустить вторую копию цикла, если lock2 занят - то запускать не будет.
    Можно, конечно, просто добавить скрипт цикла в /etc/rc.local, но если он сдохнет - то уже потом не запустится.
    Ответ написан
  • Выполнение скрипта раз в 5 секунд Linux

    @starosta6123
    Вспомнил:
    # watch --interval=5 /var/filter.sh

    еще полезное применение watch
    nsk.lug.ru/poleznye-sovety/poleznye-sovety-komanda...
    www.opennet.ru/man.shtml?topic=watch&category=1&ru...

    Можно вывод направить в /dev/null
    # watch --interval=5 /var/filter.sh > /dev/null

    Не совсем подходит под вашу цель, но возьмите на заметку.
    Запускает с интервалом в 5 секунд ваш скрипт.
    Единственное учтите, если ваш скрипт не будет успевать выполниться за пять секунд, то может быть эффект "лавинного рождения новых процессов". Особенно может возникнуть, если скрипт использует блокировки.

    А со sleep очень просто ru.wikipedia.org/wiki/Sleep

    /var/filter.sh
    #!/bin/sh
    echo "Начинаем..."
    while (true) 
    do
     echo "Ваш скрипт";
     sleep 5; # пауза 5 секунд
    done;
    Ответ написан
  • Как скрыть номер клиента от сотрудника?

    VYakushev
    @VYakushev
    Разработчик Android в Nowtaxi
    Насколько я понимаю, второй пункт без root-прав в Android невозможно, т.к. функции звонка можно использовать только через стандартный интерфейс. Это сделано для защиты пользователей от вредоносов. Поможет только создание АТС, которая будет переводить один номер телефона в другой и соединять. То есть девайс звонит на номер АТС с добавочным номером (ID-клиента), а АТС уже созванивается с клиентом и транслирует разговор.
    Ответ написан
  • В чем разница между коммутаторами Cisco за $15 тыс и за $2 тыс?

    В коммутаторах достаточно простые действия над пакетами выполняют контроллеры коммутационной матрицы, практически на 100% параллельно.

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

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

    Коммутатор и роутер одного класса у Cisco :
    роутер : 982.000 пакетов/сек., примерно 502.78 МБит/с
    коммутатор : 88 Гбит/с
    Ответ написан