По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
На дворе 1988 год – «Microsoft» выпустила операционную систему «MS DOS 4.0», на вершине Эвереста проведена первая в истории телетрансляция, а за окном неспешно протекает эпоха дутых, бесформенных курток :). Казалось бы, все здорово, но ребята из CCITT решают подлить масла в огонь и релизят первое описание ISDN (Integrated Services Digital Network), о котором мы и поговорим.
А что это?
В целом, ISDN это набор стандартов для передачи голоса, видео, блоков данных сети передачи данных и других сервисов по обычным каналам ТфОП (PSTN) - телефонной сети общего пользования. Одновременно. До появления Integrated Services Digital Network, телефонные системы рассматривались как инструмент передачи голоса, с некоторыми сервисами на сети.
ISDN использует временное мультиплексирование TDM (Time Division Multiplexing) и может работать с голосом и данными по одним и тем же линиям. В классических телефонных системах такого и близко не было :)
Сам по себе ISDN представляет гибрид, обеспечивая как доступ в сеть с коммутацией каналов, так и в сеть с коммутацией пакетов. Обеспечивая цифровую передачу голоса или данных, ISDN обеспечивает высокое качество передаваемых данных. По скорости: разгон до 64 кбит/с по абонентской линии и до 128 кбит/с по BRI интерфейсу в обе стороны (загрузка/передача).
В контексте семиуровневой модели OSI (Open Systems Interconnection), ISDN уютно расположился на 1, 2 и 3 уровнях (физический, канальный и сетевой). К первому уровню мы можем отнести BRI/PRI интерфейсы, то есть именно физические соединения, ко второму, протокол контроль ошибок физический линии (LAPD), а на третьем, то есть сетевом, расположился ОКС7 (SS7, Signaling System 7).
ISDN интерфейсы
Мы можем отметить следующие интерфейсы стандарта ISDN:
Basic Rate Interface (BRI) - в BRI интерфейсе существуют два B – канала, которые созданы для передачи данных и 1 D – канал, которые переносит сигнализацию. B – каналы разгоняются до 64 кбит/с, а D – канал гоняет на скорости 16 кбит/c. Кстати, B – канала живут свои жизнью независимо – например, по первому может установиться TCP/IP сессия, а по второму передаваться факс;
Более подробно про BRI можно почитать в нашей статье;
Primary Rate Interface (PRI) - слышали про Е1 - поток? ИКМ 30? Это оно и есть. Условно говоря, PRI состоит из D – сигнального канала (двух, в случае Е1) и от 23 до 30 B – каналов, или как их еще называют, тайм слотов (от TDM).;
Мы тут сравнивали PRI и SIP. Почитать можно тут :)
Broadband-ISDN (B-ISDN) - это так называемый «широкополосный ISDN». Это некое уточнение, спецификация к стандарту, которая расширяет параметры обычного ISDN. Он создан для сетевых служб, которые требуют широкую полосу пропускания;
ISDN службы
Условно, сервисы, которые отдает ISDN можно поделить на три категории:
Передача информации - если говорить прямым языком, «перенос» данных (голос, видео и данные) между пользователями. Сервис живет на нижних трех уровнях модели OSI. ISDN сможет «переносить» данные поверх сетей с коммутацией – каналов/пакетов/фреймов. В данном случае, ISDN не производит никаких манипуляций с содержимым блоков данных;
Телеслужбы - то, что живет от 4 до 7 уровня модели OSI. Вот тут, сеть может менять содержимое пакетов по определенным алгоритмам. ISDN сможет работать с телетекстом, факсом, видеоконференциями. То есть по факту, это некие данные, которые исходят от приложений;
Дополнительные услуги - голосовая почта, вторая линия прочие сервисы, которые могут строить компании поверх ISDN. И зарабатывать на этом :);
Основные принципы ISDN
Как мы сказали в начале статьи, ISDN живет по правилам, описанные CCITT (сейчас это всем известный ITU-T). Вот на чем ребята из ITU – T делают основные акценты:
Поддержка разнородных приложений в ISDN;
Поддержка не только голосовых сервисов;
Акцент на 64 кбитных коннекциях;
Интеллектуальность сети;
Распределенная по уровням архитектура ISDN (по аналогии с OSI);
Огромное разнообразие конфигурации сети;
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через SSH, клонировать клонировать репозиторий с новым кодом, собрать его и запустить через командную строку. Да, такой способ работает, но он малоэффективен. Сегодня мы поговорим об автоматизации процесса разработки и выхода новых версий.
CI и CD – это два сокращения, которые означают Continuous Integration (Непрерывная интеграция) и Continuous Delivery (Непрерывное развертывание).
CI
CI описывает процесс добавления изменений в репозиторий. Ниже схематически представлен простой пример коллективной разработки.
Одновременно может работать целая группа людей, но все изменения передаются в главную ветку master поэтапно. Хотя даже в такой простой схеме возникает несколько вопросов.
Как мы узнаем, что код, который идет в ветку master, компилируется?
Мы хотим, чтобы разработчики писали тесты для кода. Как быть уверенными в том, что тестовое покрытие не уменьшится?
Все сотрудники команды должны форматировать код в соответствие с определенным стилем. Как отследить возможные нарушения?
Конечно же, все это можно проверить вручную. Но такой подход весьма хаотичен. Кроме того, по мере разрастания команды выполнять подобные проверки становится сложнее.
CI используется для автоматизации выше обозначенных пунктов.
Начнем с первого пункта. Как можно проверить, что новые изменения не сломают сборку? Для этого нам потребуется еще один блок в схеме.
Большинство CI-процессов можно описать по следующему алгоритму.
При открытии каждого Pull Request (запроса на включение изменений) и отправке новых изменений, Git-сервер отправляет уведомление CI-серверу.
CI-сервер клонирует репозиторий, проверяет исходную ветку (например bugfix/wrong-sorting) и сливает ее с основной веткой master.
Затем запускается скрипт сборки. Например ./gradlew build.
Если команда возвращает код «0», то сборка прошла успешно. Все остальные значения считаются ошибкой.
CI-сервер отправляет запрос на Git-сервер с результатом сборки.
Если сборка прошла без ошибок, то Pull Request разрешается слить. В противном случае он блокируется.
Данный процесс гарантирует, что код, попадающий в ветку master, не сломает дальнейшие сборки.
Проверка тестового покрытия
Давайте немного усложним задачу. Предположим, нам захотелось установить минимальный охват тестового покрытия. Это означает, что в любой момент времени покрытие ветки master должно быть не менее 50%. Плагин Jacoco идеально справляется с этой задачей. Вы просто настраиваете его так, чтобы при охвате тестового покрытия ниже допустимого, сборка уходила в ошибку.
Реализовать такой подход проще некуда. Но есть небольшая оговорка. Этот метод работает только при условии, что плагин настраивался на старте проекта.
Представим ситуацию: вы работаете над проектом, которому уже 5 лет. С момента первого коммита никто не проверял тестовое покрытие. Разработчики добавляли тесты в случайном порядке и без какой-либо организации. Но вот однажды вы решаете увеличить количество тестов. Вы настраиваете плагин Jacoco на минимальную планку в 60%. Спустя какое-то время разработчик открывает новый Pull Request. Затем разработчики вдруг понимают, что покрытие – всего лишь 30%. Так что для успешного закрытия задачи нужно покрыть не менее 30% кода продукта. Как вы можете догадаться, для проекта 5-летней давности – это практически неразрешимая проблема.
Но что, если будут проверяться только будущие изменения в коде, а не весь продукт? Если в Pull Request разработчик изменит 200 строк, то нужно будет охватить не менее 120 из них (при тестовом покрытии в 60%). Тогда не придется проходить по множеству модулей, которые не относятся к задаче. В принципе, проблема решаема. Но как применить все это к проекту? К счастью, есть решение.
Отчет Jacoco отправляется на сервер тестового покрытия.
Одно из самых популярных решений – SonarCloud.
Сервер хранит статистику по предыдущим вычислениям. Это очень удобно: вычислять тестовое покрытие не только всего кода, но и будущих изменений. Затем результат анализа отправляется на CI-сервер, который перенаправляет его на Git-сервер.
Такая рабочая модель позволяет применять культуру обязательного тестирования на любой стадии развития продукта, поскольку проверяется лишь часть изменений.
Если говорить о стиле оформления кода, то отличий практически нет. Можете попробовать плагин Checkstyle. Он автоматически отклоняет сборку, которая нарушает любое из заявленных требований. Например, в коде есть неиспользованный импорт. Кроме того, вы можете присмотреться к облачным сервисам, которые выполняют анализ кода и визуально отображают результаты в виде графиков (SonarCloud это тоже умеет).
CD
CD описывает процесс автоматического развертывания новой версии продукта.
Давайте еще немного подкорректируем схему CI. Вот так конвейерный процесс CI/CD мог бы выглядеть в реальном проекте.
Первое отличие – теперь CI-сервер называется CI/CD-сервером. Дело в том, что зачастую оба процесса (CI и CD) выполняются одним и тем же диспетчером задач. Так что мы будем рассматривать именно этот случай.
Но так бывает не всегда. Например, задачи по интеграции могут делегироваться на GitLab CI, а задачи по доставке – отдаваться в Jenkins.
Правая часть схемы изображает CI. Мы обсудили ее выше. Слева показана CD. Задача по CD создает проект (или повторно использует артефакты, полученные на стадии CI) и развертывает его на конечном сервере.
Стоит отметить, что сервер в нашем случае – это понятие абстрактное. Например, развертывание может выполняться в кластер Kubernetes. Так что самих серверов может быть несколько.
Обычно после стадии развертывания на почту приходят сообщения о выполнении. Например, CD-сервер может уведомлять подписчиков об успешном развертывании/ошибках.
В любом случае, возникает важный вопрос. В какой момент мы должны запускать задачи по CD? Триггеры могут быть разными.
Развертывание после каждого слияния Pull Request.
Развертывание по расписанию.
Развертывание после каждого слияния Pull Request с определенной веткой.
Сочетание нескольких вариантов.
В первом пункте процесс выстроен так, что задачи по CI и CD всегда выполняются последовательно. Данный подход весьма популярен при разработке программ с исходным кодом. Библиотека Semantic Release помогает настроить проект для прозрачной интеграции данной модели.
Важно помнить о трактовке понятия deploy (развертывание). Это не всегда «что-то где-то запустить». Например, при разработке библиотеки, нет никакого запуска. В данном случае процесс развертывания означает выпуск новой версии библиотеки.
Второй пункт не зависит от процесса CI, ведь проект развертывается по определенному расписанию. Например, ежедневно в 01:00.
Третий пункт аналогичен первому, но с небольшими отличиями. Предположим, в репозитории у нас есть 2 основные ветки: develop и master. В develop содержатся самые последние изменения, а в master – только релизы версий. Если мы хотим развертывать только ветку master, то не нужно вызывать CD-задачу по слиянию в develop.
Последний пункт – это сочетание подходов. Например, ветку develop можно развертывать по расписанию в среду разработки. А ветку master – в реальную среду по каждому слиянию Pull Request.
Инструменты
На рынке доступно множество решений по автоматизации процессов CI/CD. Ниже представлено несколько продуктов.
Jenkins. Один из самых востребованных инструментов CI/CD в мире. Свою популярность он заслужил, благодаря политике открытого кода (open-source). То есть вам не нужно ни за что платить. В Jenkins вы можете императивно описывать конвейеры сборки с помощью Groovy. С одной стороны это достаточно гибкое решение, но с другой – требует более высокого уровня квалификации.
GitHub Actions. Этот инструмент для CI/CD доступен для GitHub и GitHub Enterprise. В отличие от Jenkins, GitHub Actions предлагает декларативные сценарии сборки с YAML-конфигурацией. Кроме того, в данном решении доступна интеграция с различными системами обеспечения качества (например SonarCube). Таким образом, сборку можно описать в нескольких текстовых строках.
GitLab CI. Во многом похож на GitHub Actions, но со своими особенностями. Например, GitLab CI может указывать на определенные тесты, вызывающие ошибку в сборке.
Travis CI. Облачный CI/CD-сервис. Предлагает множество возможностей, не требующих сложных настроек. Например, шифрование данных, которые следует скрыть в публичном репозитории. Есть и приятный бонус в том, что Travis CI можно совершенно бесплатно использовать в публичных open-source проектах на GitHub, GitLab и BitBucket.
Gzip – один из самых популярных алгоритмов сжатия, который позволяет сократить размер файла, но при этом сохранить исходный файловый режим, владельца объекта и отметку времени.
Gzip является отсылкой к формату файлов .gz и утилите gzip, используемой для сжатия и распаковки файлов.
В данной статье мы покажем, как использовать команду gzip.
Синтаксис команды gzip
Общий синтаксис команды gzip выглядит следующим образом:
gzip [ПАРАМЕТР]... [ФАЙЛ]...
Gzip сжимает отдельные файлы и создает сжатый файл для каждого заданного файла в отдельности. По определению имя файла, который был сжат с помощью Gzip, должно оканчиваться на .gz или .z.
Если вам необходимо сжать несколько файлов или каталогов в один файл, то для начала вам нужно создать архив Tar, а затем уже сжать файл с разрешением .tar с помощью Gzip. Файл, оканчивающийся на .tar.gz или .tgz, представляет собой архив Tar, сжатый с помощью Gzip.
Как правило, Gzip используют для сжатия текстовых файлов, архивов Tar и веб-страниц. Не нужно использовать Gzip для сжатия изображений, аудиофайлов, PDF-документов и других файлов в двоичном формате, поскольку они уже являются сжатыми.
gzip может сжимать только обычные файлы. символические ссылки он игнорирует.
Сжатие файлов с помощью gzip
Для того, чтобы сжать один файл, вызовите команду gzip, за которой следует имя файла:
gzip имя_файла
gzip создаст файл с именем имя_файла.gz, а исходный файл удалит.
По умолчанию gzip сохраняет в сжатом файле временную метку, файловый режим, владельца объекта и имя исходного файла.
Сохранение исходного файла
Если вы хотите, чтобы исходный файл был сохранен, воспользуйтесь параметром –k:
gzip -k имя_файла
Есть еще один вариант сохранить исходный файл – воспользоваться параметром -c, который сообщает gzip о необходимости записи в стандартный вывод и перенаправлении вывода в файл:
gzip -c имя_файла > имя_файла.gz
Подробный вывод
Если вы хотите увидеть процент уменьшения размера файла и имена обрабатываемых файлов, тогда воспользуйтесь параметром -v:
gzip -v имя_файла
имя_файла: 7.5% -- replaced with имя_файла.gz
Сжатие нескольких файлов
В качестве аргументов команде вы можете передать несколько файлов. Например, чтобы сжать файлы с именами file1, file2, file3, вам необходимо выполнить следующую команду:
gzip file1 file2 file3
После чего приведенная выше команда создаст три сжатых файла: file1.gz, file2.gz, file3.gz.
Сжатие всех файлов в каталоге
Для того, чтобы сжать все файлы в каталоге, воспользуйтесь параметром -r:
gzip -r имя_каталога
gzip рекурсивно пройдет через всю структуру каталогов и произведет сжатие всех файлов в каталоге и его подкаталогах.
Изменение уровня сжатия
gzip дает возможность указать уровень сжатия, его диапазон - от 1 до 9. -1 или --fast означает самую высокую скорость сжатия с минимальной степенью сжатия, -9 или --best - самую низкую скорость с максимальной степенью. По умолчанию уровень сжатия равен -6.
Например, чтобы установить максимальный уровень сжатия, вам необходимо запустить следующую команду:
gzip -9 имя_файла
Сжатие – это задача, интенсивно использующая ЦП. Соответственно, чем выше уровень сжатия, тем больше времени занимает процесс.
Использование стандартного ввода
Для того, чтобы создать файл расширения .gz из стандартного ввода, вам необходимо передать вывод команды gzip. Например, чтобы сжать резервную копию базы данных MySQL, вам необходимо запустить следующую команду:
mysqldump имя_базы_данных | gzip -c > имя_базы_данных.sql.gz
Вывод команда mysqldump послужит вводом для gzip.
Распаковка файлов с помощью gzip
Для того, чтобы распаковать файл с расширением .gz, воспользуйтесь параметром -d:
gzip -d имя_файла.gz
Есть также еще одна команда, которую вы можете использовать для распаковки файла Gzip, - это gunzip. Эта команда по сути является альтернативным вариантом команды gzip -d:
gunzip имя_файла.gz
Сохранение сжатого файла
Здесь, как и при сжатии файла, для того, чтобы показать gzip, что входной файл (в данном случае это сжатый файл) нужно сохранить, необходимо воспользоваться параметром -k:
gzip -dk имя_файла.gz
Распаковка нескольких файлов
Для того, чтобы распаковать несколько файлов одновременно, вам необходимо передать имена файлов в gzip в качестве аргументов:
gzip -d file1.gz file2.gz file3.gz
Распаковка всех файлов в каталоге
Для того, чтобы gzip рекурсивно распаковал все файлы в заданном каталоге, необходимо воспользоваться параметрами -d и -r:
gzip -dr имя_каталога
Перечень содержимого сжатого файла
Для того, чтобы посмотреть статистику данных сжатого файла, воспользуйтесь параметром -l:
gzip -l имя_файла
Вывод покажет имя несжатого файла, размер сжатого и несжатого файла, а также степень сжатия:
compressed uncompressed ratio uncompressed_name
130 107 7.5% имя_файла
Чтобы получить больше информации, добавьте параметр -v:
gzip -lv имя_файла
method crc date time compressed uncompressed ratio uncompressed_name
defla a9b9e776 Sep 3 21:20 130 107 7.5% имя_файла
Заключение
С помощью Gzip вы можете уменьшить размер определенного файла - команда gzip позволяет сжимать и распаковывать файлы.