Upgrade

Более двух лет назад мы писали о том, что перед каждым администратором Check Point рано или поздно встает вопрос обновления на новую версию. В данной статье было описано обновление с версии R77.30 до R80.10. К слову, в январе 2020-го R77.30 стала сертифицированной версией ФСТЭК. Однако за 2 года в Check Point многое изменилось. В статье Check Point Gaia R80.40. Что будет нового? описаны все нововведения, коих много. В данной статье процедура обновления будет описана максимально подробно.

Как известно, существует 2 варианта внедрения Check Point: Standalone и Distributed, то есть без выделенного сервера управления и с выделенным. Вариант Distributed является крайне рекомендованным по нескольким причинам:

• минимизируется нагрузка на ресурсы шлюза;

• можно не планировать окно для обслуживания, чтобы провести работы с сервером управления;

• адекватная работа SmartEvent, так как в Standalone варианте едва ли он будет работать;

• кластер из шлюзов крайне рекомендуется строить в Distributed конфигурацией.

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

Обновление Security Management Server (SMS)

Существует 2 способа обновления SMS:

• с помощью CPUSE (через Gaia Portal)

• с помощью Migration Tools (требуется чистая установка - fresh install)

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

Чистая установка и миграция политик с помощью Migration Tools - вот рекомендуемый метод. Помимо новых файловой системы и ядра ОС часто бывает, что база данных SMS засоряется, и чистая установка в этом плане - отличный выход, чтобы добавить скорости работы серверу.

1) Первым шагом при любом обновлении является создание бэкапов и снэпшотов. Если у вас имеется физический сервер управления, то бэкап следует сделать из веб-интерфейса Gaia Portal. Зайдите во вкладку Maintenance > System Backup > Backup. Далее вы указываете место сохранения бэкапа. Это может быть SCP, FTP, TFTP сервер или же локально на устройстве, однако тогда придется позже это бэкап скинуть на сервер или компьютер.

2) Далее следует сделать снэпшот во вкладке Maintenance > Snapshot Management > New. Отличия бэкапов от снэпшотов заключается в том, что снэпшоты хранят в себе больше информации, в том числе все установленные хотфиксы. Тем не менее, лучше сделать и то, и то.

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

3) Сохранить конфигурацию устройства из Gaia Portal. Можно заскриншнотить все вкладки настроек, которые есть в Gaia Portal, либо же из Clish ввести команду save configuration <filename>. Далее следует файл с помощью WinSCP или другого клиента забрать к себе на ПК.

Примечание: если WinSCP не дает подключиться, смените пользователю shell на /bin/bash либо в веб-интерфейсе во вкладке Users, либо введя команду chsh s /bin/bash <username>.

4) Первые 3 шага являются обязательными для любого варианта обновления. Если же вы решили пойти по более простому пути обновления, то в веб-интерфейсе перейдите во вкладку Upgrades (CPUSE) > Status and Actions > Major Versions > Check Point R80.40 Gaia Fresh Install and Upgrade. Нажмите правой клавишей мыши на данное обновление и выберите Verifier. Запуститься процесс проверки на несколько минут, по истечении которых вы увидите сообщение, что устройство может быть обновлено. Если вы видите ошибки, их необходимо исправить.

Рисунок 4. Обновление через CPUSE

5) Обновите до последней версии CDT (Central Deployment Tool) - утилиту, которая запущена на сервере управления и позволяет устанавливать обновления, пакеты обновлений, управлять бэкапами, снэпшотами, скриптами и многим другим. Неактуальная версия CDT может привести к проблемам в обновлении. Скачать CDT можно по ссылке.

6) Поместив скачанный архив на SMS в любую директорию через WinSCP, подключитесь по SSH к SMS и зайдите в экспертный режим. Напомню, что пользователь WinSCP должен иметь shell /bin/bash!

7) Введите команды:

cd /somepathtoCDT/

tar -zxvf <NameofCDTPackage>.tgz

rpm -Uhv --force CPcdt-00-00.i386.rpm

Рисунок 5. Установка Central Deployment Tool (CDT)

8) Следующим шагом является установка образа R80.40. Правой клавишей мыши на обновление Download, затем Install. Имейте в виду, что обновление занимает минут 20-30, и сервер управления будет недоступен какое-то время. Следовательно, имеет смысл согласовать окно для обслуживания.

9) Все лицензии и политики безопасности сохраняются, поэтому далее вам следует скачать новую SmartConsole R80.40.

10) Подключитесь к SMS новой SmartConsole и установите политики безопасности. Кнопка Install Policy в левом верхнем углу.

11) Ваш SMS обновлён, далее следует установить самый последний хотфикс. Во вкладке Upgrades (CPUSE) > Status and Actions > Hotfixes нажмите на правую клавишу мыши Verifier, затем Install Update. Устройство само уйдет в перезагрузку после установки обновления.

Рисунок 6. Установка последнего хотфикса через CPUSE

4) Для начала следует так же обновить до последней версии CDT - пункты 5, 6, 7 из раздела Обновление с помощью CPUSE.

5) Установите пакет Migration Tools необходимый для миграции политик с сервера управления. По данной ссылке можно найти Migration Tools для версий: R80.20, R80.20 M1, R80.20 M2, R80.30, R80.40. Скачивать следует Migration Tools той версии, на которую вы хотите обновиться, а не той, которая у вас сейчас! В нашем случае это R80.40.

6) Далее в веб-интерфейсе SMS идем во вкладку Upgrades (CPUSE) > Status and Actions > Import Package > Browse > Выбираем скачанный файл > Import.

Рисунок 7. Импорт Migration Tools

7) Из экспертного режима на SMS проверьте, что пакет Migration Tools установлен с помощью команды (вывод команды должен совпадать с числом в названии архива Migration Tools):

cpprod_util CPPROD_GetValue CPupgrade-tools-R80.40 BuildNumber 1

Рисунок 8. Проверка установки Migration Tools

8) Перейдите в папку $FWDIR/scripts на сервере управления:

cd $FWDIR/scripts

9) Запустите pre-upgrade verifier (проверочный скрипт) с помощью команды (если есть ошибки, исправьте их перед дальнейшими шагами):

./migrate_server verify -v R80.40

Примечание: если видите ошибку Failed to retrieve Upgrade Tools package, но вы проверили, что архив успешно импортирован (см. пункт 4), используйте команду:

./migrate_server verify -v R80.40 -skip_upgrade_tools_check

Рисунок 9. Запуск скрипта проверки

10) Экспортируйте политики безопасности с помощью команды:

./migrate_server export -v R80.40 /<Full Path>/<Name of Exported File>.tgz

Рисунок 10. Экспорт политики безопасности

Примечание: если видите ошибку Failed to retrieve Upgrade Tools package, но вы проверили, что архив успешно импортирован (пункт 7), используйте команду:

./migrate_server export -skip_upgrade_tools_check -v R80.40 /<Full Path>/<Name of Exported File>.tgz

11) Посчитайте MD5 хэш-сумму и сохраните себе вывод команды:

md5sum /<Full Path>/<Name of Exported File>.tgz

Рисунок 11. Высчитывание MD5 хэш-суммы

12) С помощью WinSCP переместите данный файл к себе на компьютер.

13) Введите команду df -h и сохраните себе процентное соотношение директорий, исходя из занимаемого места.

Рисунок 12. Процентное соотношение директорий на SMS

14.1) В случае, если у вас реальный SMS

14.1.1) С помощью Isomorphic Tool создается загрузочная USB флешка с образом Gaia R80.40.

14.1.2) Рекомендую подготовить минимум 2 загрузочные флешки, так как бывает, что не всегда читается флешка.

14.1.3) От имени администратора на компьютере запустите ISOmorphic.exe. В пункте 1 выбираете скачанный образ Gaia R80.40, в пункте 4 флешку. Пункты 2 и 3 изменять не надо!

Рисунок 13. Создание загрузочной флешки

14.1.4) Выбираете пункт Install automatically without confirmation и важно указать модель вашего сервера управления. В случае с SMS следует выбрать 3 или 4 строка.

Рисунок 14. Выбор модели устройства для создания загрузочной флешки

14.1.5) Далее вы выключаете аплайнс, вставляете флешку в USB порт, подключаетесь консольным кабелем через COM порт к устройству и включаете SMS. Процесс установки происходит сам собой. IP-адрес по умолчанию - 192.168.1.1/24, а данные для входа admin / admin.

14.1.6) Следующим шагом следует подключение к веб интерфейсу на Gaia Portal (адрес по умолчанию https://192.168.1.1), где вы проходите инициализацию устройства. Во время инициализации вы в основном нажимаете Next, ибо почти все настройки можно поменять в будущем. Однако вы можете изменить сразу IP-адрес, настройки DNS и hostname.

14.2) В случае, если у вас виртуальный SMS

14.2.1) Ни в коем случае не следует удалять старый SMS, создайте новую виртуальную машину с такими же ресурсами (CPU, RAM, HDD) с тем же IP-адресом. Кстати, RAM и HDD можете добавить, так как версия R80.40 чуть более требовательна. Дабы не было конфликта IP-адресов, выключите старый SMS и начните установку нового.

14.2.2) Во время установки Gaia настройте актуальный IP-адрес и выделите под директорию /root адекватное количество места. Процентное соотношение директорий у вас должно примерно сохраниться, используйте вывод df -h.

15) На моменте выбора типа установки Installation Type выбирайте первый вариант, так как, скорее всего, у вас не MDS (Multi-Domain Server). Если MDS, то значит вы управляли многими доменами из под разных сущностей SMS одновременно. Выбирать в это случае следует второй пункт.

Рисунок 15.Выбор типа установки Gaia

16) Самый важный момент, который нельзя исправить без переустановки - выбор сущности. Следует выбрать Security Management и нажать Next. Далее все по умолчанию.

Рисунок 16. Выбор типа сущности при установке Gaia

17) Как только устройство перезагрузится, подключитесь к веб интерфейсу по https://192.168.1.1 или другому IP-адресу, если вы меняли его.

18)Перенесите настройки из скриншотов во все вкладки Gaia Portal, в которых что-то было настроено или же из clish выполните команду load configuration <filename>.txt. Данный файл конфига следует предварительно закинуть на SMS.

Примечание: ввиду того, что ОС новая, WinSCP не даст подключиться под админом, смените пользователю shell на /bin/bash либо в веб-интерфейсе во вкладке Users, либо введя команду chsh s /bin/bash <username> или создайте нового пользователя.

19) Закиньте в любую директорию файл с экспортированными политиками со старого сервера управления. Затем зайдите в консоль к экспертный режим и проверьте, что MD5 хэш сумма совпадает с прежней. В противном случае экспорт следует делать заново:

md5sum /<Full Path>/<Name of Exported File>.tgz

20) Повторите пункт 6 и установите Upgrade Tools на новый SMS в Gaia Portal во вкладке Upgrades (CPUSE) > Status and Actions.

21) Введите команду в экспертном режиме:

./migrate_server import -v R80.40 -skip_upgrade_tools_check /<Full Path>/<Name of Exported File>.tgz

Рисунок 17. Импорт политики безопасности на новый SMS

22) Включите сервисы командой cpstart.

23) Скачайте новую SmartConsole R80.40 и подключитесь к серверу управления. Зайдите в Menu > Manage Licenses and Packages (SmartUpdate) и проверьте, что у вас сохранилась лицензия.

Рисунок 18. Проверка установленных лицензий

24) Установите политику безопасности на шлюз или кластер - Install Policy.

Обновление Security Gateway (SG)

Шлюз безопасности можно обновить через CPUSE, так же как и сервер управления, или установить заново - fresh install. Из моей практики в 99% случаев все заново устанавливают Security Gateway ввиду того, что это занимает практически столько же времени, как и обновление через CPUSE, однако вы получаете чистую обновленную ОС без багов.

По аналогии с SMS сперва требуется создать бэкап и снэпшот, а также сохранить настройки из Gaia Portal. Обратитесь к пунктам 1, 2 и 3 в разделе "Обновление Security Management Server".

1.1) В случае, если у вас реальный SG

1.1.1) С помощью Isomorphic Tool создается загрузочная USB флешка с образом Gaia R80.40. Образ тот же самый, что и на SMS, однако немного иначе выглядит процедура создания загрузочной флешки.

1.1.2) Рекомендую подготовить минимум 2 загрузочные флешки, так как бывает, что не всегда читается флешка.

1.1.3) От имени администратора на компьютере запустите ISOmorphic.exe. В пункте 1 выбираете скачанный образ Gaia R80.40, в пункте 4 флешку. Пункты 2 и 3 изменять не надо!

Рисунок 19. Создание загрузочной флешки

1.1.4) Выбираете пункт Install automatically without confirmation, и важно указать модель вашего Security Gateway - строки 2 или 3. Если это физическая песочница (SandBlast Appliance), то выбираем строку 5.

Рисунок 20. Выбор модели устройства для создания загрузочной флешки

1.1.5) Далее вы выключаете аплайнс, вставляете флешку в USB порт, подключаетесь консольным кабелем через COM порт к устройству и включаете шлюз. Процесс установки происходит сам собой. IP-адрес по умолчанию - 192.168.1.1/24, а данные для входа admin / admin. Сперва следует обновлять пассивную ноду, затем установить на нее политику, переключить роли и потом обновить другую ноду. Скорее всего, понадобится окно для обслуживания.

1.1.6) Следующим шагом следует подключение к веб интерфейсу на Gaia Portal, где вы проходите первую инициализацию устройства. Во время инициализации вы в основном нажимаете Next, ибо почти все настройки можно поменять в будущем. Однако вы можете изменить сразу IP-адрес, настройки DNS и hostname.

1.2) В случае, если у вас виртуальный SG

1.2.1) Создайте новую виртуальную машину с такими же ресурсами (CPU, RAM, HDD) или больше, так как версия R80.40 чуть более требовательна. Дабы не было конфликта IP-адресов выключите старый шлюз и начните установку нового с тем же IP-адресом. Старый SG можно спокойно удалить, так как ничего ценного на нем нет, ибо все самое главное - политика безопасности - находится на сервере управления.

1.2.2) Во время установки ОС настройте актуальный IP-адрес и выделите под директорию /root адекватное количество места.

3) Подключитесь по HTTPS порту к шлюзу и начните процесс инициализации. На моменте выбора типа установки Installation Type выберите первый вариант - Security Gateway and/or Security Management.

Рисунок 21. Выбор типа установки Gaia

4) Важнейший момент - выбор сущности (Products). Следует выбрать Security Gateway и, если у вас кластер, поставить галочку Unit is a part of a cluster, type: ClusterXL. Если у вас кластер VRRP, то выберите такой тип, но это маловероятно.

Рисунок 22. Выбор типа сущности при установке Gaia

5)В следующем шаге задайте одноразовый пароль SIC для установления доверия с сервером управления. С помощью этого пароля генерируется сертификат, и по шифрованному каналу взаимодействия сервер управления будет общаться со шлюзом. Галочку Connect to your Management as a Service следует ставить, если сервер управления находится в облаке. Мы буквально недавно написали об этом статью и о том, насколько удобен и прост облачный менеджмент сервер.

Рисунок 23. Создание SIC

6) Начните процесс инициализации на следующей вкладке. Как только устройство перезагрузится, подключитесь к веб интерфейсу и перенесите настройки из скриншотов во все вкладки Gaia Portal, в которых что-то было настроено или же из clish выполните команду load configuration <filename>.txt. Данный файл конфига следует предварительно закинуть на шлюз безопасности.

Примечание: ввиду того, что ОС новая, WinSCP не даст подключиться под админом, смените пользователю shell на /bin/bash либо в веб-интерфейсе во вкладке Users, либо введя команду chsh s /bin/bash <username> или создайте нового пользователя с таким shell.

7) Откройте SmartConsole R80.40 и зайдите в объект шлюза безопасности, который вы только что переустановили. Откройте вкладку General Properties > Communication > Reset SIC и введите пароль, заданный в пункте 5.

Рисунок 24. Установка доверия с новым шлюзом безопасности

8) Версия Gaia у объекта должна смениться, если не изменится, то поменяйте ее руками. Затем установите политику на шлюз.

9) В Gaia Portal зайдите во вкладку Upgrades (CPUSE) > Status and Actions > Hotfixes и установите последний хотфикс. Устройство уйдет в перезагрузку во время установки!

10) В случае кластера, смените роли нод и проделайте те же шаги для другой ноды.

Заключение

Я постарался сделать максимально понятный и всеобъемлющий гайд по обновлению с версии R80.20/R80.30 до актуальной на данный момент R80.40, так как многое изменилось. Версия Gaia R81 уже появилась в демо режиме, однако процедура обновления более или менее остается идентична. Руководствуясь официальным гайдом от Check Point, вы и сами сможете разобраться во всех тонкостях.

По всем вопросам вы можете обращаться к нам. Мы будем рады помочь с самыми сложными обновлениями и кейсами в рамках нашей технической поддержки CPSupport. Также на нашем сайте есть возможность заказать аудит настроек Check Point или оставить бесплатную заявку на технический кейс.

Большая подборка материалов по Check Point от TS Solution. Следите за обновлениями (Telegram, Facebook, VK, TS Solution Blog, Яндекс.Дзен).

Хочу представить перевод довольно интересной статьи Сэма Редмонда, Why We Should Throw Out React and Pick Up Angular. На мой взгляд, статья описывает основные возможности Angular. Она может показаться довольно вызывающей, но постарайтесь отнестись к ней немного с юмором :)

Итак, я уже немного написал о том, почему, как мне кажется, мы должны перестать использовать React. Чтобы подвести итог этой статьи, я перечислю несколько проблем, с которыми я столкнулся в React:

1. Он популярен в основном от того, что вокруг него много шумихи.

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

3. Использует не оправдано много памяти и не поддаётся оптимизации(not tree-shakable).

4. Сложность React приложения растёт экспоненциально с ростом размера приложения и это затрудняет его обслуживание.

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

6. Обновление вашего приложения до последней версии React часто сопряжено с полным переписыванием этого самого приложения.

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

All aboard the hype train

Angular также получает изрядное количество хайпа, так что я не могу сказать, что Angular решает эту проблему. Однако, я не думаю, что Angular получает такое же количество хайпа, как React. Мне кажется, что в основном это связано с ребрендингом, который сделал Google.. Сначала был AngularJs, который был как дымящаяся куча мусора. Но надо отдать должное Google, они решили полностью отремонтировать AngularJs и превратить его в Angular (или Angular 2), что является гигантским улучшением. Впрочем, это улучшение стоило ему популярности, как мне кажется.

Лично я думаю, что им следовало бы переименовать Angular во что-то другое, потому что AngularJs и Angular совсем не похожи. Единственное сходство - это названия фреймворков и компания, которая их разработала.

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

Вы получаете то, что вам нужно

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

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

Кроме того вы получаете такую штуку, как Angular CLI, который один из самых мощных инструментов на поясе у Angular.

Одна из самых больших проблем с React - это отсутствие стандартов. Если вы изучили одно React приложение, то вы изучили одно React приложение, потому что все они совершенно разные. С другой стороны, если вы изучили одно Angular приложение, то вы изучили все Angular приложения и Angular CLI является основным драйвером, стоящим за этим.

В отличие от React в Angular есть правильные и неправильные способы. Использование Angular CLI обычно всегда гарантирует, что всё будете делать правильно. Давайте возьмём самое начало. Мы хотим создать новое приложение. Как мы это сделаем?

ng new my-app

Да, вот, пожалуй и всё. Запустите эту команду и CLI настроит кучу вещей за вас. Он даже даст вам некоторый выбор, такой как использование линтинга и роутинга, перед тем, как будет создано приложение. Итак, вот что сделает CLI:

1. Он создаст новую директорию my-app и проинициализирует в ней Angular приложение. А также установит зависимости.

2. Настраивает инфраструктуру и интегрирует в неё приложение, снабдив вас всем, что нужно для запуска.

3. Вместе с инфраструктурой вы также получаете встроенную базовую реализацию end-to-end тестов на Protractor, в которую вы можете добавлять тесты, по мере развития вашего приложения.

4. Angular даёт вам простой в использовании конфигурационный файл (angular.json). В нём вы можете легко настроить, как Angular собирает приложение и даже то, как эта сборка делается средой окружения.

5. Говоря о среде окружения, Angular имеет в своём составе простую и хорошо типизированную систему управления этой самой средой.

Ещё много есть того, чего я возможн коснусь, но и это уже очень круто, да ещё и прямо из коробки. В React вы такого не получите. Что ещё даёт вам CLI?

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

ng generate component my-component OR ng g c my-component

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

1. Создаёт директорию с именем my-component и помещает в него пустой компонент.

2. Автоматически генерирует unit tests для данного компонента.

3. Автоматически встраивает ваш компонент в инфраструктуру приложения.

Путь Angular

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

https://stackblitz.com/edit/angular-examples-modules

ng g m buttonng g c button

В этом примере у нас есть папка button. В этой папке есть модуль button, компонент button, тестовый файл, файл стилей и HTML файл.

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

Чтобы всё было просто, давайте импортируем это в app.module.ts. Всё, что мы сделаем, это импортируем наш компонент ButtonModule в app.module.ts и потом включим его в раздел imports декоратора @NgModule приложения AppModule.

Вот и всё. Теперь мы можем использовать тэг <app-button></app-button> в app.component.html файле.

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

Доставьте меня из пункта А в пункт Б

Я хотел бы коснуться ещё одной фичи, которую предоставляет вам Angular из коробки. Это роутинг и ленивая загрузка модулей. Я не буду здесь сильно углубляться и приведу небольшой пример. Если вы хотите подробнее разобрать эти фичи, попробуйте это сделать своими руками в Angular.

Как хороший CLI, Angular имеет опции. Одна из них задействует роутинг во время создания инфраструктуры приложения.

ng new my-app --routing

На сегодняшний день вы можете просто выбрать опцию во время установки, без указания флага. Но флаг тоже можно указывать, если вы так больше предпочитаете. Когда вы выбираете routing, Angular создаёт файл роутинга за вас. Он будет служить вам в качестве основного конфигурационного файл. Если вы захотите создать модули для ваших страниц, вы также можете указать флаг routing. CLI тогда создаст конфиг роутинга для этого модуля.

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

const routes: Routes = [   {   path: 'main',   loadChildren: () =>    import('src/app/routes/main/main.module').then((mod) => mod.MainModule)   },];

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

Переиспользование делает вашу жизнь проще

Итак, мы рассмотрели, как Angular использует Modules для организации страниц и компонент и хочу остановиться на этом немного подробнее. Вероятно, что вы уже знаете, что Angular использует TypeScript вместо обычного javascript. Это явное преимущество Angular использует в полной мере.

Полагаю, что вы уже говорите - React тоже использует TypeScript, и будете правы. Но React использует Typescript не в полной мере. Типизация - это только часть того, что делает TypeScript таким продвинутым. Другая часть состоит в том, что вы можете в полной мере использовать классы и декораторы. React дал ясно понять, что движется в сторону функциональных компонент, а не в сторону компонент основанных на классах, что отнимает половину всей мощи TypeScript. Теперь стало намного сложнее переиспользовать функциональность в моём приложении и оно стало более сложным в обслуживании.

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

@my-decorator()export class MyClass {}

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

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

Understanding Angular Ivy: Incremental DOM and Virtual DOM

В предыдущей статье я немного рассказывал о том, что виртуальный DOM это своего рода пожиратель памяти и что невозможно оптимизировать расход этой памяти (tree shaking), поскольку виртуальное дерево создаётся всякий раз заново при перерисовке. Всё изменилось с приходом Angular Ivy. Вы сможете прочитать как работает Ivy в статье Виктора. Я лишь приведу некоторые моменты из неё.

Angular Ivy использует так называемый инкрементный DOM. Идея заключается в том, что каждый компонент ссылается на набор инструкций, которые известны на стадии компиляции. И если некоторые инструкции не используются, то они исключаются из сборки.

В отличие от виртуального DOM, в инкрементном DOM память расходуется при перерисовке дерева DOM, если только в нем произошли изменения (то есть были удалены или добавлены элементы). Кроме того, выделение памяти пропорционально размеру изменений. Это здорово повышает эффективность в рантайме, особенно для мобильных устройств.

Помните, как я ранее сказал: Я уже знаю, что вы думаете и мы к этому вернёмся? Давайте разберём это. В том месте статьи я уверен, что вы подумали про себя: это всё прелестно, но что если мне не понадобиться ВСЁ, что Angular предоставляет? Хорошо, ну вы сами вдумайтесь, если вы не используете какую-то часть Angular, она просто не попадёт в сборку! Их технология оптимизации сборки постоянно улучшается и вы получите более стройные билды, в особенности если вы не используете абсолютно всё, что есть в Angular.

Апгрейд - проще простого

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

Я долго работал с Angular и видел все апдейты с первого релиза (я даже работал с AngularJs, но предпочитаю не говорить об этом). Безусловно Angular прошёл долгий путь, как и CLI. Где в 2018 году в Angular CLI появилась ещё одна команда - ng update. Вы можете использовать её так:

ng update @angular/core

Дальше происходит магия. Все зависимости ядра Angular обновятся до последней версии. Если ваш код нуждается в обновлении, CLI сделает это за вас и, если нельзя, то скажет, где вам нужно самим вручную обновить свой код. Обновление до последней версии Angular займёт от нескольких секунд до нескольких минут, в то время, как с React это может занять от нескольких часов до нескольких дней (или даже недель).

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

Давайте свяжем всё вместе

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

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

Хорошая совместимость - уменьшение сложности обслуживания. Когда ваш проект растёт, стоимость обслуживания не будет возрастать экспоненциально. Наверное это самая большая проблема в React приложениях, которую превосходно решает Angular. Следуя тому же ходу мысли, мы также получаем всё, что нам нужно прямо из ядра Angular. Обработка форм? Пожалуйста. Роутинг? Пожалуйста. Ленивая загрузка? Пожалуйста. Я мог бы продолжить, но остановлюсь на этом. Даже если вы что-то не используете, то это не войдет в ваш билд, потому что всё, что в ядре Angualr является оптимизируемым деревом (tree shakable), включая рендеринг.

Чтобы завершить статью, скажу последнее. Используйте Angular. Смотрите видео на YouTube. Читайте документацию или учитесь, как у вас получается лучше всего. А затем смело бросайте React в мусор, потому что он вам больше не понадобится.

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

Поздравляем с выходом версии 1.20. Третий релиз в 2020 году, в котором 11 фич объявили stable, 15 перевели в beta и добавили 16 новых в alpha-стадии.

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

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

Второе важное изменение, которое может сломать ваш продакшен, заключается в том, что в версии 1.20 починили баг с таймаутами для Probe типа exec.

В описании контейнеров в манифесте подов есть специальный раздел, описывающий каким образом можно узнать, что приложение живое и готово обрабатывать входящие запросы. С помощью HTTP/TCP-запроса или запуска (exec probe) какого-либо процесса внутри контейнера (например, rabbitmqctl status) и анализа кода завершения.

Суть проблемы в следующем:

В манифесте есть поле timeoutSeconds:, которое задает максимальное время ожидания ответа на запрос или время выполнения процесса внутри контейнера. Ошибка была в том, что при выполнении exec probe этот параметр не учитывался и процесс внутри контейнера мог работать бесконечно долгое время, пока сам не завершится.

Ошибку исправили, и в версии 1.20 все стало прекрасно. Но не для всех.

Если вы используете exec probe и указывали timeoutSeconds: в своих манифестах самое время проверить, укладывается ли время выполнения вашей пробы в таймаут.

А вот если вы не указывали timeoutSeconds:, то у меня для вас не очень хорошая новость. Значение по умолчанию для этого параметра 1 секунда, если ваша проба выполняется дольше, то успешной она явно не будет.

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

И к другим новостям:

Если вы пользовались alpha feature API Priority and Fairness (APF) в своем мульти-мастер кластере 1.19 выключайте ее перед обновлением. В 1.20 она переведена в статус beta, но в процессе перевода отломали совместимость с alpha. После обновления она будет включена по умолчанию.

Мастеров больше не будет! Метка node-role.kubernetes.io/master и taint node-role.kubernetes.io/master:NoSchedule, которые по умолчанию ставил kubeadm на узлы с запущенными компонентами control-plane, объявлены deprecated и скоро будут убраны. Вместо них будут использоваться метка node-role.kubernetes.io/control-plane и taint node-role.kubernetes.io/control-plane:NoSchedule.

В kubeadm усилили проверки входящих параметров serviceSubnet и podSubnet.

Сеть для сервисов теперь имеет ограничение на размер и не должна аллоцировать более 20 бит. В переводе на человеческий это означает, что размер сети для IPv4 должен быть /12 или меньше (/13, /14 и т.п.), а для IPv6 /108, но лучше будет использовать /112.

Сеть для подов теперь проверяется на совместимость с параметром --node-cidr-mask-size, размер сетей, выделяемых на узел должен быть меньше, чем сеть для подов.

Из API сервера убрали возможность беспарольного входа. Теперь не получится восстановить потерянный доступ к кластеру, просто зайдя на мастер и добавив в ключи запуска API сервера ключ --insecure-port 8080

IPv4/IPv6 dual stack был немножко переписан в части реализации сервисов. Один сервис теперь может иметь как IPv4, так и IPv6 адрес (при включении "IPv6DualStack" feature gate). Но это привело к несовместимым изменениям в API. Изменился манифест Kind: Service вместо одного поля ipFamily теперь будет целых три: ipFamilyPolicy, ipFamilies, clusterIPs. Пишут, что большинству пользователей ничего не надо будет делать, сервисы останутся только IPv4, пока не включен соответствующий feature gate. TODO: Посмотреть, что там с Headless Service, которым в манифесте указываем clusterIP: None

Команда для работы с сертификатам (проверки, генерации или продления kubeadm alpha certs переименована в kubeadm certs. Старый вариант вызова еще работает, но в следующих релизах его уберут.

Анонсировали фичу GracefulNodeShutdown при ее включении kubelet будет самостоятельно завершать все запущенные поды, при выключении узла. Соблюдая все обычные gracefulShutdown таймауты и вызывая preStop хуки.

Команда kubectl debug повышена до беты, и в ее описании появилось много различных возможностей. Запуск дополнительных эфемерных дебаг контейнеров в поде, создание копий пода и замена команды запуска. Единственная тонкость новое название команды конфликтует с плагином debug, и теперь вместо плагина будет выполнятся встроенная команда. Если вы хотите продолжать пользоваться плагином, то его придется переименовать.

В процессе починки CVE-2020-8559 немножко усилили безопасность, что может привести к поломке работы бэкендов расширения API, таких как metrics-server или prometheus adapter.

Выпущен новый CronJob controller v2. Видимо, чинить баги старого контроллера больше не могут, и решили выпустить новый, с новыми багами. Пока в стадии альфа, так что включать его надо с помощью специального feature gate.