Здравствуйте уважаемые начинающие веб-мастера. Начинаем изучать языки программирования.

И начнём мы их изучать с html.

Сразу скажу, что в конце курса Вы уже сможете самостоятельно написать сайт на чистом html, и выложить его в интернет. Но я всё же порекомендую не торопиться, и после html, познакомиться с css.

Тогда и сайт Вы сделаете покруче, и сможете исправлять внешний вид сайта, созданного на готовой CMS(система управления контентом).

Изучение языка программирования, и изучение иностранного языка — это далеко не одно и тоже, и оно гораздо легче. Более того, это не страшно, а очень увлекательно.

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

Учиться мы будем при помощи редактора , который Вам нужно установить на свой компьютер.

В этом редакторе файлов, можно написать код, и тут-же посмотреть, как отобразит его браузер. Очень удобно.

Давайте, сначала я Вам немного расскажу, что из себя представляет HTML, и это будет скучная часть нашего курса, а затем займёмся интереснейшей практикой. Там уж, точно, скучно не будет.

НТМL (HyperText Markup Language) дословно — язык разметки гипертекста. С помощью его создаются веб-страницы.

И если, совокупность просто страниц, объединённых одной тематикой, в нашем понимании — книга, или даже, лучше сказать, толстый журнал, то совокупность веб-страниц объединённых одним доменным именем — это и есть сайт.

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

Код — это команды браузеру, как отображать тот или иной элемент. Допустим, написали Вы слово, а вот в каком виде оно будет на экране, зависит от того, в какой код вы его заключите.

Код html состоит из следующих элементов:

2. Атрибуты тегов.

3. Значения атрибутов.

Давайте рассмотрим их по порядку.

Тег html — это основной элемент кода. Пишется он так:

Как видите, состоит он из двух частей. Первые угловые скобки — это открывающая часть, а вторые, со слешем — закрывающая.

Между этими двумя частями, пишется весь остальной код страницы, которая будет отображаться на экране.

Тег сообщает браузеру, что это html-документ, и является основным (родительским) тегом для всех остальных элементов.

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

Например, если поставить в угловых скобках букву h1 , то на экране выведется текст в виде заголовка.

Здравствуйте

То есть шрифт слова «Здравствуйте», будет крупнее и жирнее остального текста.

Если в угловые скобки поставить букву p , то текст заключённый в тег, будет выведен в виде абзаца.

Здравствуйте

То есть, шрифт будет обычный, но всё, что написано после этого тега, будет начинаться с новой строки.

И таких букв, и даже слов, определяющих вид команды, в html несколько десятков, хотя в частом использовании находятся не больше 10-15 тегов.

Более подробно, каждый из них, мы рассмотрим по ходу

Следующие — это атрибуты тегов. Часто используемых, тоже не более десятка. А в последнее время и того меньше, так как все функции атрибутов перенесены в css.

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

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

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

Это указание и будет значением атрибута. Выглядит оно так:

Это красный цвет.

Точно так же, но при помощи других атрибутов, можно задавать размер текста, отступы, выравнивания, и много чего ещё.

Хотя, оформление всё больше переходит к CSS, а атрибуты оформления постепенно устаревают и выходят из практики.

А сейчас делаем вывод из всего вышесказанного:

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

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

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

Полный список тегов и атрибутов html, если кому то интересно, всегда можно посмотреть в . .

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

Ну, и всё, пожалуй. Мало? А больше пока и не надо. Остальное будем узнавать в процессе обучения на конкретных примерах.

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

Перемена

Только сядешь за учёбу — так обязательно какая-то падла разбудит!!!

В школе учитель говорит ученикам:
— Кто из вас окончательно считает себя тупицей? Встаньте.
После долгой паузы поднимается один ученик:
— Так ты считаешь себя тупицей?
— Ну не совсем, но как — то неловко, что вы стоите один.

Ruby

• Tutorial

Здравствуйте.

Этот топик открывает цикл статей по использованию системы управления конфигурацией Puppet .

Что такое система управления конфигурацией?

Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете ОС (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфиги ваших любимых текстовых редакторов (nanorc, vimrc), выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.

Я искренне верю, что хороший админ - ленивый админ. Он не любит делать что-то несколько раз. Первая мысль - написать пару скриптов, в котором будет что-то наподобие:

Servers.sh
servers="server00 server01 server02 server03 server04" for server in $servers ; do scp /path/to/job/file/job.sh $server:/tmp/job.sh ssh $server sh /tmp/job.sh done

Job.sh
#!/bin/bash apt-get update apt-get install nginx service nginx start

Вроде всё стало легко и хорошо. Нужно что-то сделать - пишем новый скрипт, запускаем. Изменения приходят на все серверы последовательно. Если скрипт хорошо отлажен - всё станет хорошо. До поры.

Теперь представьте, что серверов стало больше. Например, сотня. А изменение долгое - например, сборка чего-нибудь большого и страшного (например, ядра) из исходников. Скрипт будет выполняться сто лет, но это полбеды.

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

Самое плохое - это то, что в подобных скриптах вы описываете действия , которые необходимо выполнить для приведения системы в определенное состояние, а не само это состояние. Значит, если система изначально находилась не в том состоянии, что вы предполагали, то всё обязательно пойдет не так. Манифесты Puppet декларативно описывают необходимое состояние системы, а вычисление, как к нему прийти из текущего состояния - задача самой системы управления конфигурацией.

Для сравнения: манифест puppet, выполняющий ту же работу, что и пара скриптов из начала топика:

Nginx.pp
class nginx { package { "nginx": ensure => latest } service { "nginx": ensure => running, enable => true, require => Package["nginx"] } } node /^server(\d+)$/ { include nginx }
Если правильно использовать серверы и потратить некоторое время на первичную настройку системы управления конфигурацией, можно добиться такого состояния парка серверов, что вам не потребуется логиниться на них для выполнения работы. Все необходимые изменения будут приходить к ним автоматически.

Что такое Puppet?

Puppet - система управления конфигурацией. Архитектура - клиент-серверная, на сервере хранятся конфиги (в терминах puppet они называются манифесты ), клиенты обращаются к серверу, получают их и применяют. Puppet написан на языке Ruby, сами манифесты пишутся на особом DSL, очень похожем на сам Ruby.

Первые шаги

Давайте забудем о клиентах, серверах, их взаимодействии и т.п. Пусть у нас есть только один сервер, на котором установлена голая ОС (здесь и далее я работаю в Ubuntu 12.04, для других систем действия будут несколько отличаться).

Сначала установим puppet последней версии.

Wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb dpkg -i puppetlabs-release-precise.deb apt-get update apt-get install puppet puppetmaster

Замечательно. Теперь у нас в системе установлен puppet и с ним можно играть.

Hello, world!

Создадим первый манифест:

/tmp/helloworld.pp
file { "/tmp/helloworld": ensure => present, content => "Hello, world!", mode => 0644, owner => "root", group => "root" }
И применим его:

$ puppet apply helloworld.pp /Stage//File/ensure: created Finished catalog run in 0.06 seconds

Немного о запуске

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

Теперь посмотрите на содержимое файла /tmp/helloworld. В нём окажется (удивительно!) строка «Hello, world!», которую мы задали в манифесте.

Вы можете сказать, что можно было сделать echo "Hello, world!" > /tmp/helloworld , это было бы быстрее, проще, не пришлось бы думать, писать какие-то страшные манифесты и вообще это нафиг никому не нужно это как-то слишком сложно, но задумайтесь серьезнее. На самом деле, необходимо было бы написать touch /tmp/helloworld && echo "Hello, world!" > /tmp/helloworld && chmod 644 /tmp/helloworld && chown root /tmp/helloworld && chgrp root /tmp/helloworld , чтобы гарантированно добиться того же результата.

Давайте по строкам разберём, что именно содержится в нашем манифесте:

/tmp/helloworld.pp
file { "/tmp/helloworld": ensure => present, # файл должен существовать content => "Hello, world!", # содержимым файла должна являться строка "Hello, world!" mode => 0644, # права на файл - 0644 owner => "root", # владелец файла - root group => "root" # группа файла - root }

В терминах Puppet здесь описан ресурс типа файл с названием (title) /tmp/helloworld .

Ресурсы

Ресурс - это самая мелкая единица абстракции в Puppet. Ресурсами могут быть:

• файлы;
• пакеты (Puppet поддерживает пакетные системы многих дистрибутивов);
• сервисы;
• пользователи;
• группы;
• задачи cron;
• и т. д.

Синтаксис ресурсов вы можете невозбранно подсмотреть .

В Puppet есть возможность добавлять свои ресурсы. Поэтому если хорошенько заморочиться, можно докатиться до манифестов наподобие:

Webserver.pp
include webserver; webserver::vhost { "example.com": ensure => present, size => "1G", php => false, https => true }
Puppet при этом будет создавать logical volume размером в 1 ГиБ на сервере, монтировать его куда положено (например в /var/www/example.com), добавлять нужные записи в fstab, создавать нужные виртуальные хосты в nginx и apache, рестартовать оба демона, добавлять в ftp и sftp пользователя example.com с паролем mySuperSecretPassWord с доступом на запись в этот виртуальный хост.

Вкусно? Не то слово!

Причем, самое вкусное, на мой взгляд - это не автоматизация рутины. Если вы например, идиот, и постоянно пересетапливаете ваши серверы в продакшне, Puppet позволит подхватить старый любовно созданный набор пакетов и конфигов с нуля в полностью автоматическом режиме. Вы просто устанавливаете Puppet-агент, подключаете его к вашему Puppet-мастеру и ждёте. Всё придёт само. На сервере волшебным (нет, правда волшебным!) образом появятся пакеты, разложатся ваши ssh-ключи, установится фаервол, придут индивидуальные настройки bash, сети, установится и настроится весь софт, который вы предусмотрительно ставили с помощью Puppet.
Кроме того, Puppet при старании позволяет получить самодокументируемую систему, ибо конфигурация (манифесты) сами же являются костяком документации. Они всегда актуальны (они же работают уже), в них нет ошибок (вы же проверяете свои настройки перед запуском), они минимально подробны (работает же).

Ещё немного магии

Немного о кроссдистрибутивности

В Puppet есть возможность использовать кроссдистрибутивные манифесты, это одна из целей, для которых он создавался. Я намеренно никогда не пользовался этим и вам не рекомендую. Парк серверов должен быть максимально гомогенным в плане системного ПО, это позволяет не думать в критические моменты «айблин, тут
rc.d, а не init.d» (реверанс в сторону ArchLinux) и вообще позволяет меньше думать на рутинных задачах.

Многие ресурсы зависят от других ресурсов. Например, для ресурса «сервис sshd» необходим ресурс «пакет sshd» и опционально «конфиг sshd»
Посмотрим, как это реализуется: file { "sshd_config": path => "/etc/ssh/sshd_config", ensure => file, content => "Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes", mode => 0644, owner => root, group => root, require => Package["sshd"] } package { "sshd": ensure => latest, name => "openssh-server" } service { "sshd": ensure => running, enable => true, name => "ssh" subscribe => File["sshd_config"], require => Package["sshd"] }

Здесь используется инлайн-конфиг, который делает манифест некрасивым. На самом деле так почти никогда не делается, существует механизм шаблонов, основанный на ERB, и возможность просто использовать внешние файлы. Но нас не это интересует.

Самые вкусные строчки здесь - это строчки зависимостей - require и subscribe.

Puppet поддерживает много вариантов описания зависимостей. Подробно, как всегда, можно прочитать в

Статья написана в журнале Системный администратор

World Revolution

Управление множеством Unix систем нельзя называть комфортабельным. Для конфигурации 1-го параметра администратору приходится обращаться к каждой машине, скрипты только частично могут помочь, ну и не во всех ситуациях.

Следует признать, что администраторы Windows сетей находятся все-таки в более успешном положении. Достаточно поменять функции групповых политик и через некоторое время все компютеры сети, в том числе и с не так издавна установленной операционной системой “выяснят” о нововведении, если они их естественно касаются.

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

Коммерческие решения вроде BladeLogic и OpsWare , делему автоматизации опций решают только отчасти, основное их достоинство наличие графического интерфейса, ну и позволить их приобрести могут только в огромных организациях. Есть естественно и проекты предлагающие свободные решения, но за всегда собственного существования они так и не смогли сделать большого общества.

Например Cfengine не очень пользуется популярностью у администраторов, хотя не считая Linux, может употребляться в *BSD, Windows и Mac OS X. Может быть это связано с относительной сложностью в разработке конфигураций. При описании заданий приходится учитывать особенности каждой определенной системы, и вручную контролировать последовательность действий при выполнении команд.

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

Не смотря на GPL лицензию Cfengine фактически проект 1-го человека, который контролирует все конфигурации и не очень заинтересован в построении открытого общества. В конечном итоге возможности cfengine вполне удовлетворяют разработчика, а для других администраторов это резвее лишняя боль в голове.

Чтобы улучшить cfengine сторонними разработчиками были изготовлены различные дополнения, что часто только ухудшало ситуацию. Создатель нескольких таких модулей к cfengine Люке Каниес (Luke Kanies) в итоге решил сделать похожий инструмент, но лишенный многих недостатков cfengine.

Возможности Puppet

Puppet как и cfengine является клиент-серверной системой использующей декларативный, другими словами неотклонимый для выполнения язык для описания задач и библиотеки для их реализации. Клиенты периодически (по умолчанию 30 минут) соединяются с центральным сервером и получают последнюю конфигурацию.

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

Дополнительные уровни абстракции Transactional и Resource обепечивают наивысшую сопоставимость с существующими опциями и приложениями, позволяя сфокусироваться на системных объектах, не заботясь о различиях в реализации и описании подробных команд и форматах файлов. Администратор оперирует только с типом объекта, остальное Puppet берет на себя. Так тип packages знает о Семнадцать пакетных системах, подходящая автоматом будет распознана на основании инфы о версии дистрибутива или системы, хотя при необходимости пакетный менеджер можно задать принудительно.

В отличие от скриптов, которые часто не может быть использовать в других системах, конфигурации Puppet написанные сторонними администраторами будут в большинстве без заморочек работать в хоть какой другой сети. В Puppet CookBook уже имеется три 10-ка готовых рецептов. В настоящее время Puppet официально поддерживает следующие операционные системы и сервисы: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo и MySQL, LDAP.

Язык Puppet

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

В отличие от большинства похожих решений, в Puppet язык позволяет упростить обращение ко всем схожим ресурсам на хоть какой системе в гетерогенной среде. Описание ресурса, обычно, состоит из наименования, типа и атрибутов. Например укажем на файл /etc/passwd и установим его атрибуты:

file { «/etc/passwd»:

owner => root,

group => root,

На данный момент клиенты, подключившись к серверу скопируют файл /etc/passwd и установят обозначенные аттрибуты. В одном правиле можно определять слету несколько ресурсов, разделяя их с помощью точки с запятой.

А что делать если конфигурационный файл используемый на сервере отличается от клиентских или вообще не употребляется? Например такая ситуация может показаться при настройках VPN соединений. В этом случае следует на файл можно указать директивой source.

Здесь два варианта, как обычно указать путь к другому файлу, также поддерживается два URI протокола: file и puppet. В первом случае употребляется ссылка на внешний NFS сервер, во втором варианте на сервере Puppet, запускается NFS похожий сервис, который и экспортирует ресурсы.

В последнем случае по умолчанию путь указывается относительно корневого каталога puppet - /etc/puppet. Другими словами ссылка puppet://server.domain.com/config/sshd_config будет соответствовать файлу /etc/puppet/config/sshd_config.

Переопределить этот каталог, можно с помощью директивы filebucket, хотя более правильно использовать одноименную секцию в файле /etc/puppet/fileserver.conf. В этом случае можно ограничить доступ к сервису только с определенных адресов. Например опишем секцию config.

path /var/puppet/config

allow *.domain.com

allow 192.168.0.*

allow 192.168.1.0/24

deny *.wireless.domain.com

А позже обращаемся к этой секции при описании ресурса.

source => «puppet://server.domain.com/config/sshd_config»

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

file { «/etc/passwd»:

alias => passwd

Другой вариант сотворения псевдонима, прекрасно подходит в данном случае, когда приходится иметь дело с разными операционными системами. Например, создадим ресурс описывающий файл sshd_config:

file { sshdconfig:

name => $operatingsystem ? {

solaris => «/usr/local/etc/ssh/sshd_config»,

default => «/etc/ssh/sshd_config»

В этом примере мы столкнулись с возможностью выбора. Раздельно указан файл для Solaris, для всех других будет избран файл /etc/ssh/sshd_config. На данный момент к этому ресурсу можно обращаться как к sshdconfig, зависимо от операционной системы будет избран подходящий путь.

Например укажем, что в случае если бес sshd запущен и получен новый файл, следует перезапустить сервис.

ensure => true,

subscribe => File

Переменные часто используются при работе с пользовательскими данными. Например описываем месторасположение домашнних каталогов юзеров:

$homeroot = «/home»

На данный момент к файлам определенного пользователя можно обратиться как

${homeroot}/$name

В параметр $name будет подставлено учетное имя пользователя. В некоторых случаях комфортабельно отыскать значение по умолчанию для некоторого типа. Например для типа exec очень часто указывают сборники в каких он должен отыскивать исполняемый файл:

Exec { path => «/usr/bin:/bin:/usr/sbin:/sbin» }

В том случе если нужно указать на несколько вложенных файлов и каталогов, можно использовать параметр recurse.

file { «/etc/apache2/conf.d»:

source => «puppet:// puppet://server.domain.com/config/apache/conf.d»,

recurse => «true»

Несколько ресурсов могут быть объеденены в классы или определения. Классы являются законченным описанием системы или сервиса и употребляются обособленно.

«/etc/passwd»: owner => root, group => root, mode => 644;

«/etc/shadow»: owner => root, group => root, mode => 440

Как и в объектно-ориентированных языках классы могут переопределяться. Например в FreeBSD группой-владельцем этих файлов является wheel. Поэтому чтобы не переписывать ресурс полностью, создадим новый класс freebsd, который будет наследовать класс linux:

class freebsd inherits linux {

File["/etc/passwd"] { group => wheel };

File["/etc/shadow"] { group => wheel }

Для удобства все классы можно вынести в отдельный файл, который подключать директивой include. Определения могут принимать многочисленные свойства в качестве аргументов, но не поддерживают наследования и употребляются в данном случае если нужно описать не один раз используемые объекты. Например определим домашний каталог юзеров и команды нужные для сотворения новой учетной записи.

define user_homedir ($group, $fullname, $ingroups) {

user { «$name»:

ensure => present,

comment => «$fullname»,

gid => «$group»,

groups => $ingroups,

membership => minimum,

shell => «/bin/bash»,

home => «/home/$name»,

require => Group[$group],

exec { «$name homedir»:

command => «/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name»,

Шла о том, что такое управление конфигурацией и как внедрить эту технологию в свою инфраструктуру.

Примечание : Руководство выполнено на Ubuntu 14.04 и Apache.

Данное руководство поможет подготовить автоматизированную оркестровку сервера с помощью инструмента конфигурационного управления Puppet. Вы ознакомитесь с основными терминами, синтаксисом и функциями Puppet. В результате вы получите полностью автоматизированное простое развёртывание, которое состоит из таких этапов:

• Обновление индекса пакетов.
• Установка Apache.
• Создание пользовательского каталога document root.
• Создание в нём файла index.html.
• Применение шаблона для установки пользовательского виртуального хоста.
• Перезапуск Apache.

Примечание : Данное руководство сосредоточено на создании манифестов – сценариев Puppet для автоматизации настройки. Больше о Puppet можно прочитать в статьях:

Начало работы

Прежде чем приступить к разработке манифеста, нужно ознакомиться с основными терминами Puppet.

Терминология Puppet

• Мастер Puppet: ведущий сервер, который управляет настройкой нод.
• Агент Puppet: ведомая нода, которая подчиняется мастеру.
• Манифест: сценарий оркестровки.
• Ресурс: фрагмент кода, который определяет необходимые системе изменения.
• Модуль: группа манифестов и других файлов, организованная заранее определенным образом, которая позволяет облегчить совместное и повторное использование ее отдельных частей оркестровки.
• Класс: как и в любом обычном языке программирования, классы отвечают за организацию и повторное использование частей оркестровки.
• Факты: глобальные переменные системы.
• Сервисы: изменяют статус сервиса (запуск, остановка и т.д.).

Оркестровка Puppet разрабатывается на языке DSL, который основан на Ruby.

Ресурсы

Puppet определяет задачи с помощью ресурсов. Ресурсы могут представлять пакеты, файлы, сервисы, пользователей и команды. Они могут иметь состояние, которое будет приводить к изменению системы в случае, если состояние заявленного ресурса отличается от текущего состояния системы. Например, ресурс package с состоянием installed в манифесте запустит установку пакета, если такой пакет не был установлен ранее. Такой ресурс выглядит так:

package { "apache2":

ensure => "installed"

Ресурс exec позволяет выполнить любую команду:

exec { "apt-get update":

command => ‘/usr/bin/apt-get update’

Обратите внимание: apt-get update в приведённом выше примере является не объявлением команды, а идентификатором ресурса. Часто в Puppet нужно ссылаться на другие ресурсы, и для этого используются их идентификаторы.

Зависимость ресурсов

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

В качестве примера можно привести следующий код; он определяет зависимость ресурса, а уже затем сам ресурс:

package { "python-software-properties":

ensure => "installed"

}
exec { "add-repository":

command => "/usr/bin/add-apt-repository ppa:ondrej/php5 -y"
require => Package["python-software-properties"]

Опция require получает в качестве параметра ссылку на другой ресурс. В данном случае ресурс Package определяется пакетом python-software-properties.

Примечание : Объявления ресурсов начинаются с маленькой буквы (exec, package), а зависимости – с большой (Exec, Package).

К примеру, вам нужно сделать так, чтобы одна задача выполнялась перед второй. Для этого используется опция before.

package { "curl":

ensure => "installed"
before => Exec["install script"]

exec { "install script":

command => "/usr/bin/curl http://example.com/some-script.sh"

Формат манифестов

Манифесты – это наборы ресурсов с расширением.pp. Ниже приведён пример простого манифеста, который выполняет две задачи: обновляет индекс пакетов и устанавливает vim.

exec { "apt-get update":

command => "/usr/bin/apt-get update"

}
package { "vim":

ensure => "installed"
require => Exec["apt-get update"]

Примечание : В конце данного руководства вы найдёте полный код манифеста Puppet.

Написание манифеста

Переменные

Переменные можно определить в любой части манифеста. Наиболее распространёнными типами переменных являются строки и массивы строк, но Puppet поддерживает и другие типы.

Этот код определяет строку переменной, которую в дальнейшем можно использовать в манифесте:

$package = "vim"
package { $package:

ensure => "installed"

Циклы

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

Проще всего определить цикл в Puppet с помощью массива, например:

$packages = ["vim", "git", "curl"]
package { $packages:

ensure => "installed"

С версии 4 Puppet поддерживает дополнительные пути для перебора задач. Приведенный ниже код делает то же самое, что и предыдущий код, но на этот раз используется итератор each. Эта опция упрощает создание циклов ресурсов:

$packages.each |String $package| {
package { $package:

ensure => "installed"

Использование условных выражений

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

Puppet поддерживает большую часть условных структур традиционных языков программирования (например, выражения if/else и case); кроме того, некоторые ресурсы (например, exec), поддерживают атрибуты, которые работают как условные выражения, но принимают как условие только выходные данные команды.

Допустим, вы хотите выполнить команду, основываясь на факте. В таком случае, чтобы проверить значение переменной, вам необходимо использовать одну из поддерживаемых условных структур поддерживается, например if/else:

if $osfamily != "Debian" {

warning("This manifest is not supported on this OS.")

notify { "Good to go!": }

Также условные выражения часто используются в IT-автоматизации, если выполнение одной команды зависит от вывода другой команды. В таких случаях используются onlyif или unless, как показано в примере ниже. Следующая команда будет выполнена только в том случае, если вывод /bin/which php успешен:

command => "/bin/echo PHP is installed here > /tmp/test.txt",
onlyif => "/bin/which php"

Аналогично, выражение unless выполнит команду, только если команда в unless не была выполнена.

command => "/bin/echo PHP is NOT installed here > /tmp/test.txt",
unless => "/bin/which php"

Использование шаблонов

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

• Embedded Puppet (EPP): работает только с Puppet 4+.
• Embedded Ruby (ERB)

Ниже приведён пример шаблона ERB для создания виртуального хоста Apache, в котором используется переменная для создания корневого каталога этого хоста:

ServerAdmin webmaster@localhost
DocumentRoot <%= @doc_root %>
>
AllowOverride All
Require all granted

Чтобы применить шаблон, нужно создать ресурс file, который отображает содержание шаблона с помощью метода template. Чтобы заменить виртуальный хост Apache по умолчанию, используйте такой шаблон:

ensure => "present",
content => template("apache/vhost.erb")

В данном случае Puppet будет искать шаблон vhost.tpl в каталоге apache/templates.

Определение сервисов

Ресурсы сервисов изменяют состояние системного сервиса (например, останавливают или перезапускают его).

Рассмотрим предыдущий пример шаблона, который предназначен для создания виртуального хоста Apache. Чтобы обеспечить перезагрузку Apache после изменения виртуального хоста, нужно создать ресурс сервиса. Это делается так:

service { "apache2":

ensure => running,
enable => true

Чтобы определить ресурс, используйте опцию notify.

file { "/etc/apache2/sites-available/000-default.conf":

ensure => "present",
content => template("vhost.erb"),
notify => Service["apache2"]

Пример манифеста

Теперь можно собрать весь код данного руководства в один манифест, который будет автоматизировать установку Apache в Ubuntu 14.04.

Примечание: Дополненный вариант манифеста можно найти на Github . Также эта папка содержит файл Vagrant, который позволяет протестировать манифест на упрощённой установке с помощью виртуальной машины Vagrant .

$doc_root = "/var/www/example"
exec { "apt-get update":

command => "/usr/bin/apt-get update"

}
package { "apache2":

ensure => "installed",
require => Exec["apt-get update"]

}
file { $doc_root:

ensure => "directory",
owner => "www-data",
group => "www-data",
mode => 644

}
file { "$doc_root/index.html":

ensure => "present",
source => "puppet:///modules/main/index.html",
require => File[$doc_root]

}
file { "/etc/apache2/sites-available/000-default.conf":

ensure => "present",
content => template("main/vhost.erb"),
notify => Service["apache2"],
require => Package["apache2"]

}
service { "apache2":

ensure => running,
enable => true

• В первой строке находится переменная $doc_root, которая в дальнейшем используется для объявления ресурса.
• Строки 3-5: ресурс exec выполняет команду apt-get update.
• Строки 7-10: ресурс package устанавливает пакет apache2, зависит от apt-get update. То есть этот ресурс будет выполнен только если выполнится требуемый ресурс.
• Строки 12-17: ресурс file создаёт новый корневой каталог. Ресурс file может создавать файлы и каталоги, применять шаблоны и копировать локальные файлы на удалённый сервер. Эта задача может быть выполнена на любом этапе оркестровки, потому ей не нужны зависимости.
• Строки 19-23: ещё один ресурс file копирует файл index.html в корневой каталог на сервере. Параметр source позволяет Puppet найти исходный файл. Этот код основан на методе обработки локальных файлов в Puppet. В репозитории Github можно найти структуру каталогов, которая позволит Puppet найти этот ресурс. Корневой каталог нужно создать до выполнения этого ресурса, потому здесь применяется опция require.
• Строки 25-30: этот ресурс file применяет шаблон Apache и перезапускает сервис. В данном примере оркестровка организована с помощью модуля main (потому исходным шаблоном будет main/vhost.erb). Опция require обеспечивает выполнение ресурса только в том случае, если установлен пакет apache2.
• Строки 32-35: ресурс service перезапускает сервис apache2.

Заключение

Puppet – это производительный инструмент управления конфигурацией, который использует язык DSL для управления ресурсами сервера и автоматизации задач. Этот язык предлагает дополнительные ресурсы, которые обеспечивают гибкость оркестровки.

При работе с Puppet важно помнить, что ресурсы не всегда читаются и выполняются том же порядке, в каком они определены. Будьте очень внимательны, создавая цепочку исполнения.

Tags: ,

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

Этот раздел показывает установку и настройку Puppet в конфигурации клиент/сервер. Этот простой пример демонстрирует как установить Apache с использованием Puppet .

Установка

Для установки Puppet введите в терминале:

Sudo apt-get install puppetmaster

На клиентской машине (или машинах) введите:

Sudo apt-get install puppet

Настройка

Прежде чем настраивать puppet вам возможно захочется добавить запись DNS CNAME для puppet.example.com , где example.com - это ваш домен. По умолчанию клиенты Puppet проверяют DNS на наличие puppet.example.com в качестве имени puppet сервера (Puppet Master ). Смотрите Служба доменных имен для дополнительных деталей использования DNS .

Если вы не предполагаете использовать DNS , вы можете добавить записи в файл /etc/hosts на сервере и клиенте. Например, в файл /etc/hosts Puppet сервера добавьте:

127.0.0.1 localhost.localdomain localhost puppet 192.168.1.17 meercat02.example.com meercat02

На каждом Puppet клиенте добавьте запись для сервера:

192.168.1.16 meercat.example.com meercat puppet

Замените IP адреса и доменные имена из примера на ваши актуальные адреса и имена сервера и клиентов.

Теперь настроим некоторые ресурсы для apache2 . Создайте файл /etc/puppet/manifests/site.pp , содержащий следующее:

Package { "apache2": ensure => installed } service { "apache2": ensure => true, enable => true, require => Package["apache2"] }

Node "meercat02.example.com" { include apache2 }

Замените meercat02.example.com на актуальное имя вашего Puppet клиента.

Финальным шагом для этого простого Puppet сервера является перезапуск сервиса:

Sudo /etc/init.d/puppetmaster restart

Теперь на Puppet сервере все настроено и время настроить клиента.

Сначала настроим сервис Puppet агента для запуска. Отредактируйте /etc/default/puppet, заменив значение START на yes :

Sudo /etc/init.d/puppet start

Возвращаемся на Puppet сервер для подписи клиентского сертификата с помощью команды:

Sudo puppetca --sign meercat02.example.com

Проверьте /var/log/syslog на любые ошибки конфигурации. Если все прошло хорошо, пакет apache2 и его зависимости будут установлены на Puppet клиенте.

Этот пример очень простой и не показывает многие возможности и преимущества Puppet . Для дополнительной информации смотрите