vault backup: 2026-05-02 23:10:30
This commit is contained in:
Dmitry
@@ -1,85 +0,0 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-04-30
|
||||
title: Git
|
||||
---
|
||||
|
||||
# Git
|
||||
## Знакомство с Git
|
||||
|
||||
**Git** — система управления версиями с распределенной архитектурой, разработанная Линусом Торвальдсом в 2005 году.
|
||||
|
||||
Среди всех доступных систем управления версиями (*Git*, *Mercurial*, *CVS*, *SVN*), Git является абсолютным лидером и признанным стандартом.
|
||||
|
||||
Неоспоримыми преимуществами Git являются:
|
||||
|
||||
- Высокая производительность.
|
||||
- Безопасность.
|
||||
- Гибкость в распределенных системах.
|
||||
- Прекрасные возможности для командной работы.
|
||||
|
||||
### Производительность
|
||||
|
||||
Высокая производительность Git обусловлена подходом по *оптимизации* *внутренних* *процедур* и использованию анализа содержимого файлов Git работает с файлами, храня объекты с содержимым каталога и метаданными их версий.
|
||||
|
||||
### Безопасность
|
||||
|
||||
Безопасность при работе с Git обеспечивается целостностью исходного кода и применением алгоритма шифрования SHA1.
|
||||
Использование Git гарантирует подлинность истории изменений и защищает исходный код от тайного внесения изменений.
|
||||
|
||||
### Гибкость
|
||||
|
||||
Гибкость при работе с Git достигается за счет поддержки линейных и нелинейных циклов разработки, совместимости со множеством других информационных систем и популярных протоколов.
|
||||
|
||||
### Возможности для командной работы
|
||||
|
||||
Git обладает впечатляющими возможностями для командной работы за счет поддержки множества разнообразных моделей управления исходным кодом, удовлетворяющих нужды больших и маленьких команд, простых и сложных распределенных проектов.
|
||||
|
||||
## Модели управления исходным кодом
|
||||
|
||||
Работа с версиями исх. кода в git построена на основе использования:
|
||||
- коммитов (*commit*)
|
||||
- веток (*branches*)
|
||||
- слияния веток (*merge*)
|
||||
- сравнивания версий (*diff*)
|
||||
|
||||
На основе этих сущностей строятся разнообразные *модели управления исходным кодом*.
|
||||
|
||||
Большой популярностью пользуется модель под названием *gitflow*.
|
||||
|
||||
### GitFlow
|
||||
|
||||
**gitflow** - модель ветвления в git, в которой используются *основные ветки* (main, release, develop) и *функциональные* (features, fix).
|
||||
|
||||
1) *main* - официальная история релизов;
|
||||
2) *release* - концентрация готового к выпуску в прод функционала;
|
||||
3) *develop* - ветка для разработки функционала;
|
||||
4) *feature* - работа над любым новым функционалом ведется командой в этой ветке, после завершения разработки, ветка сливается с develop-ветки.
|
||||
|
||||
Когда в *Develop*-ветке оказывается достаточно функционала для выпуска нового релиза, на основе *Develop*-ветки создается ветка *Release*.
|
||||
|
||||
После прохождения всех тестов и проверок, *Release*-ветка сливается с остальными основными ветками — *Main* и *Develop*.
|
||||
|
||||
![[Pasted image 20260430152221.png|597]]
|
||||
Недостатки *gitflow*:
|
||||
1) Не очень хорошая совместимость с CI/CD;
|
||||
2) Не для рабочих процессах, связанных с редким выпуском релизов;
|
||||
3) Потенциально запутанная схема веток и трудности в восстановлении историчности их слияний в сложных проектах.
|
||||
|
||||
Предпочтительной моделью сегодня стала модель магистральных рабочих процессов (**TBD**).
|
||||
|
||||
### TBD
|
||||
|
||||
**TBD (Trunk Based Development)** - альтернативная модель управления исходным кодом в git на основе ветвления (как замена gitflow).
|
||||
Основана на принципе одной главной ветки, называемой "магистралью" (**trunk**).
|
||||
|
||||
Вся работа над новым функционалом ведется разработчиками в магистральной ветке, что исключает ошибки слияния и неработающие сборки.
|
||||
|
||||
Команда разработки, ведущая работу над функционалом, сохраняет свои изменения только в **trunk-ветку** и обеспечивает непрерывную сборку, тестирование и доставку нового функционала, не привязываясь к срокам и частоте выпуска релизов (выпуск релиза в любой момент).
|
||||
|
||||
![[Pasted image 20260430153712.png]]
|
||||
|
||||
Модель TBD быстро завоевала популярность в разветвленных проектах и прекрасно зарекомендовала себя в распределенных больших командах разработки за счет своей понятности, динамичности и совместимости с CI/CD-процессами.
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-04-30
|
||||
title: Gitlab
|
||||
---
|
||||
|
||||
# Gitlab
|
||||
|
||||
**Gitlab** — это веб-приложение, обеспечивающее управление репозиториями программного кода в системе контроля версий Git.
|
||||
|
||||
Установить и использовать Gitlab можно на собственном сервере или в облачной инфраструктуре.
|
||||
|
||||
Gitlab позволяет:
|
||||
|
||||
- Создавать, изменять и удалять репозитории.
|
||||
- Управлять пользователями и их правами.
|
||||
- Автоматизировать процессы CI/CD и тестирования.
|
||||
- Полнофункционально взаимодействовать с исходным кодом из веб-интерфейса.
|
||||
|
||||
Основные преимущества *Gitlab*:
|
||||
|
||||
- Гибкие возможности по планированию командной разработки.
|
||||
- Создание и управление проектами.
|
||||
- Построение процессов тестирования кода.
|
||||
- Непрерывная сборка и доставка (*CI/CD*).
|
||||
- Наблюдаемость (*Observability*).
|
||||
|
||||
*Gitlab* позволяет эффективно поддерживать и развивать выбранный вами подход по управлению исходным кодом и командной разработкой (Gitflow, TDB и другие).
|
||||
|
||||
Работа с репозиториями в *Gitlab* осуществляется посредством создания, изменения, управления, удаления проектов и работы с пользователями.
|
||||
|
||||
Функциональность *Gitlab* позволяет задействовать инструменты по управлению ветками и коммитами пользователей, обеспечивая слаженную командную работу.
|
||||
|
||||
В *Gitlab* реализованы инструменты для проведения следующих операций над исходным кодом:
|
||||
|
||||
- Code-review.
|
||||
- Оценка качества кода.
|
||||
- Тестирование.
|
||||
|
||||
Возможна настройка модели приемки качества исходного кода, его проверки и тестирования.
|
||||
|
||||
*Gitlab* обладает интегрированными инструментами, позволяющими автоматизировать рутинные операции с исходным кодом:
|
||||
|
||||
- Непрерывную сборку и доставку (*CI/CD*);
|
||||
- Тестирование новых версий;
|
||||
- Релизный цикл продукта;
|
||||
- Проверки по безопасности.
|
||||
|
||||
*Gitlab* позволяет отслеживать и обрабатывать множество важной информации о процессе разработки:
|
||||
|
||||
- Трекинг затраченного рабочего времени на разработку функционала и выпуск новых релизов;
|
||||
- Мониторинг работоспособности приложения;
|
||||
- Расширенный сбор и анализ метрик.
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
status: processing
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-04-29
|
||||
title: Введение в сетевую безопасность
|
||||
---
|
||||
|
||||
# Введение в сетевую безопасность
|
||||
|
||||
> Сетевая безопасность входит в информационную безопасность, как основная составляющая.
|
||||
|
||||
Информационная безопасность - (согласно ГОСТ № Р 5314-2008) - состояние защищенности информации, при котором обеспечены её *конфиденциальность*, *доступность* и *целостность*.
|
||||
|
||||
1) **Конфиденциальность** - недоступность информации для неавторизованных пользователей.
|
||||
2) **Целостность** - полученная информация не искажена и не подменена злоумышленником.
|
||||
3) **Доступность** - недопущение выхода из строя систем вследствие сбоев или специально внесенных ошибок конфигурации.
|
||||
|
||||
Помимо классической модели CIA (КЦД) ИБ основывается на базовых понятиях:
|
||||
1) **Идентификация** - присвоение пользователям (субъектам) и ресурсам (объектам) уникальных идентификаторов внутри ИС.
|
||||
2) **Аутентификация** - проверка подлинности пользователя.
|
||||
3) **Авторизация** - процедура контроля доступа субъектов к объектам и предоставление каждому из них именно тех прав и полномочий, которые определены *правилами доступа*.
|
||||
|
||||
Для повышения уровня ИБ в ИС, следует придерживаться следующих принципов:
|
||||
1) **Простота** - минимизация количества используемых технологий и механизмов. Способствует уменьшению поверхности атаки, в которых злоумышленник может атаковать систему.
|
||||
2) **Отказоустойчивые настройки по-умолчанию** - задание четких правил доступа к ресурсам.
|
||||
3) **Полная опосредованность** - при предоставлении доступа к ресурсу, необходимо выполнить проверку на наличие полномочий, т.е. всегда уметь определить источник запроса.
|
||||
4) **Минимизация полномочий** - система (субъект или другая ИС) должна обладать минимальным набором полномочий, необходимых для работы.
|
||||
5) **Разделение ответственности** - сегментация системы с предоставлением разным частям разных полномочий.
|
||||
|
||||
> [!info] Уязвимость
|
||||
> **Уязвимость** - это *слабое звено* ИС, которое, став известным злоумышленнику, может позволить ему нарушить её безопасность.
|
||||
> *Уязвимостями* являются, например, ошибки в программе, слабые пароли, неправильное разделение прав доступа и т.д.
|
||||
|
||||
Для исправления уязвимостей, разработчики выпускают патчи (patch - заплатка).
|
||||
|
||||
**Поиск уязвимостей** — важная часть задачи обеспечения безопасности. Эта работа включает в себя регулярное тестирование системы.
|
||||
В любой момент времени для любой системы можно указать множество различных видов уязвимостей.
|
||||
Например, для операционных систем и приложений новые уязвимости появляются чуть ли не каждый день.
|
||||
Выявлять их вручную — задача очень трудоемкая, поэтому для автоматизации поиска уязвимостей используют различные программные инструменты — средства сканирования уязвимостей, такие, например, как *OpenVAS, Nessus* и др.
|
||||
Сканирование заключается в последовательном (адрес за адресом узла, или номер за номером порта, или идентификатор за идентификатором сетевого со единения) направлении запросов целевой системе.
|
||||
Затем на основании полученных ответов генерируется "информационный отпечаток", и, наконец, сравнением "отпечатка" с записями в базе данных выполняется идентификация уязвимости.
|
||||
|
||||
**Угроза** - набор обстоятельств и действий, которые потенциально могут привести к нарушению безопасности системы.
|
||||
|
||||
**Атака** - реализованная угроза.
|
||||
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-04-24
|
||||
title: Обратное распространение ошибки - вывод
|
||||
---
|
||||
|
||||
# Обратное распространение ошибки - вывод
|
||||
|
||||
> [!note] Обозначения
|
||||
> $x_{j}$ - $j$-ый вход
|
||||
> $w_{ij}^{(1)}$ - вес от входа $j$ к скрытому нейрону $i$
|
||||
> $w_{li}^{(2)}$ - вес от скрытого нейрона $i$ к выходу $l$
|
||||
> $S_{i}^{(1)}$ - взвешенная сумма на входе нейрона $i$ в слое *1*
|
||||
> $u_{i}$ - выход нейрона $i$ слоя *1* (после активации)
|
||||
> $S_{l}^{(2)}$ - взвешенная сумма на входе нейрона $l$ слоя *2*
|
||||
> $y_{l}$ - выход нейрона $l$ слоя *2* (предсказание)
|
||||
> $d_{l}$ - истинное значение
|
||||
> $F$ - функция активации (напр. сигмоида)
|
||||
|
||||
## Прямой проход
|
||||
$$\begin{align*}
|
||||
&S_{i}^{(1)} = \sum\limits_{j=1}^{n}w_{ij}^{(1)}x_{j} \text{ - взвешенная сумма на первом слое}\\
|
||||
&u_{i}=F(S_{i}^{(1)}) \\
|
||||
&y_{l}=F(s_{l}^{(2)}) \\
|
||||
&E = \frac{1}{2}*\sum\limits_{l=1}^{m}(y_{l}-d_{l})^{2}
|
||||
\end{align*}$$
|
||||
## Обратный проход (выходной слой)
|
||||
$$\begin{align*}
|
||||
\frac{dE}{dw_{li}^{(2)}}&=\frac{dE}{dy_{l}}* \frac{dy_{l}}{dS_{l}^{(2)}}*\frac{dS_{l}^{(2)}}{dw_{li}^{(2)}}\\
|
||||
\end{align*}$$
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
status: processing
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-04-30
|
||||
title: Основные команды git
|
||||
---
|
||||
|
||||
# Основные команды git
|
||||
|
||||
`git init` - создание нового Git-репозитория (преобразование существующего проекта или создание нового пустого репозитория).
|
||||
|
||||
`git clone` - создание локальной копии удаленного Git-репозитория.
|
||||
|
||||
`git branch` - создание отдельной ветки на основе существующей для осуществления в новой ветке процесса разработки с возможным последующим слиянием.
|
||||
|
||||
`git checkout` - переключение между различными версиями целевого объекта (файлы, коммиты и ветки).
|
||||
|
||||
`git status` - отображение рабочего состояния файлов в локальной копии отслеживаемого проекта.
|
||||
|
||||
`git add` - индексирование изменений в локальной копии отслеживаемого проекта.
|
||||
|
||||
`git commit` - подготовка к отправке в удаленный репозиторий набора проиндексированных изменений в локальном проекте.
|
||||
|
||||
`git push` - выгрузка в удаленный репозиторий подготовленного набора проиндексированных изменений из отслеживаемой локальной копии.
|
||||
|
||||
`git pull` - загрузка содержимого из удаленного репозитория и немедленное слияние изменений в локальный отслеживаемый репозиторий.
|
||||
|
||||
`git restore` - отмена индексации изменений в локальном репозитории.
|
||||
|
||||
`git revert` - отмена подготовленных к отправке проиндексированных изменений в локальном репозитории с сохранением истории.
|
||||
|
||||
`git merge` - слияние ответвления (ветки ответвленной с веткой изначальной). Изменения часто проходят процедуру согласования с участниками команды разработки через механизм merge Request.
|
||||
|
||||
`git rebase` - операция, подобная слиянию (Git merge).
|
||||
|
||||
Команды `git merge` и `git rebase` решают одну и ту же проблему – слияние одной ветки в другую, но делают это по-разному.
|
||||
|
||||
**git merge** — это неразрушающая операция, существующие ветки никак не изменяются.
|
||||
|
||||
|
||||
|
||||
**git rebase** — это операция фактического перебазирования ответвленной ветки в исходную, с созданием идеальной линейной истории проекта.
|
||||
|
||||
|
||||
|
||||
> [!important] Золотое правило перебазирования:
|
||||
>
|
||||
> **"Never rebase while you're on a public branch"** - (никогда не используйте git rebase в публичных репозиториях).
|
||||
> Если вы предпочитаете иметь чистую линейную историю без ненужных коммитов слияния – используйте `git rebase`.
|
||||
>
|
||||
> Если вам необходимо сохранить полную историю проекта и избежать перезаписи публичных коммитов – используйте команду `git merge`.
|
||||
@@ -1,15 +0,0 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-04-29
|
||||
title: УИР
|
||||
---
|
||||
|
||||
# УИР
|
||||
|
||||
Тема: Анализ предметной области и существующих решений в сфере контроля посещаемости в вузах.
|
||||
|
||||
|
||||
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-04-30
|
||||
title: Шаблонизатор Helm
|
||||
---
|
||||
|
||||
# Шаблонизатор Helm
|
||||
## Helm
|
||||
|
||||
**Шаблонизатор** - это средство *упаковки приложений* для развертывания и администрирования в подконтрольной инфраструктуре.
|
||||
|
||||
**helm** - *шаблонизатор* и *менеджер* *приложений* для развертывания в среде Kubernetes.
|
||||
|
||||
**Шаблонизатор Helm** – лучший способ манипуляции над рабочими нагрузками, позволяющий:
|
||||
|
||||
- Осуществлять поиск.
|
||||
- Устанавливать.
|
||||
- Обновлять (Upgrade).
|
||||
- Удалять приложения.
|
||||
|
||||
Для начала работы с шаблонизатором Helm достаточно установить Helm-client и добавить Chart-репозиторий с необходимым приложением.
|
||||
|
||||
## Helm-Chart
|
||||
|
||||
**Helm-chart** — основная сущность Helm для создания, версионирования, распространения и публикации приложений в Kubernetes.
|
||||
|
||||
Необходимый Helm-chart можно получить двумя способами:
|
||||
|
||||
- Найти в официальном репозитории артефактов.
|
||||
- Создать свой собственный.
|
||||
|
||||
### Работа с Helm-charts
|
||||
Добавление Helm-chart репозитория:
|
||||
|
||||
```sh
|
||||
helm repo add bitnami
|
||||
```
|
||||
|
||||
[https://charts.bitnami.com/bitnami](https://charts.bitnami.com/bitnami)
|
||||
|
||||
Не забывайте своевременно обновлять helm-chart репозиторий:
|
||||
|
||||
```bash
|
||||
helm repo update
|
||||
```
|
||||
|
||||
После добавления helm-chart репозитория, возможен **поиск** доступных в репозитории charts:
|
||||
|
||||
```bash
|
||||
helm search repo bitnami
|
||||
```
|
||||
|
||||
После нахождения требуемого helm-chart можно приступить к его **установке** в kubernetes:
|
||||
|
||||
```bash
|
||||
helm install bitnami/mysql
|
||||
```
|
||||
|
||||
helm поддерживает установку с **переопределением** параметров инсталляции:
|
||||
|
||||
```bash
|
||||
helm install istiod istio/istiod --set requests.cpu=300m
|
||||
```
|
||||
|
||||
Перед инсталляцией можно ознакомиться со списком доступных **параметров** установки:
|
||||
|
||||
```bash
|
||||
helm show values istio/base
|
||||
```
|
||||
|
||||
Управление имеющимися инсталляциями (**релизами**) осуществляется централизованно:
|
||||
|
||||
```bash
|
||||
helm list
|
||||
```
|
||||
|
||||
Инсталляции (релизы) можно **обновлять** (upgrade):
|
||||
|
||||
```bash
|
||||
helm upgrade istiod istio/istiod --set requests.cpu=600m
|
||||
```
|
||||
Reference in New Issue
Block a user