📌 Как linux выбирает, какой из процессов завершить ?

💬 Спрашивают в 13% собеседований

Когда в системе Linux возникает состояние OOM (Out of Memory), в дело вступает специальный механизм под названием OOM Killer. Его задача — выбрать и завершить один или несколько процессов, чтобы освободить память и стабилизировать систему. Процесс выбора происходит на основе нескольких факторов, и система старается минимизировать ущерб при завершении процессов.

Основные факторы выбора процесса для завершения

1️⃣ OOM Score:

➕ Каждый процесс в системе имеет параметр под названием oom_score, который показывает, насколько вероятно, что данный процесс будет завершен OOM Killer. Чем выше значение, тем более вероятно, что процесс будет завершен.

2️⃣ Использование памяти:

➕ Предпочитает завершать процессы, которые потребляют больше всего памяти, так как это позволит освободить больше ресурсов сразу.

3️⃣ Приоритет процесса (niceness):

➕ Система учитывает приоритет процесса. Процессы с низким приоритетом (высоким значением niceness) более вероятно будут завершены по сравнению с процессами с высоким приоритетом.

4️⃣ Состояние процесса:

➕ Процессы, находящиеся в состоянии "спящего" (sleeping) или "ожидания" (waiting), могут быть менее приоритетными для завершения по сравнению с процессами, которые активно выполняют задачи.

5️⃣ Семейство процессов:

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

Пример: Вычисление oom_score

Система использует несколько файлов в файловой системе /proc для определения и управления поведением OOM Killer. Основные файлы:

➕ /proc/<pid>/oom_score — показывает текущий OOM score для процесса с идентификатором PID.

➕ /proc/<pid>/oom_adj и /proc/<pid>/oom_score_adj — позволяют изменить приоритет процесса для OOM Killer.

Проверка oom_score для процесса:

cat /proc/<pid>/oom_score

Настройка приоритета процесса:

echo -17 > /proc/<pid>/oom_score_

Значение -17 минимизирует вероятность того, что процесс будет выбран для завершения.

Пример

Система испытывает нехватку памяти, и его необходимо выбрать процесс для завершения. Он будет анализировать текущие процессы и их oom_score. Например:

➕ Процесс A: Использует 2 ГБ памяти, oom_score = 500

➕ Процесс B: Использует 1 ГБ памяти, oom_score = 300

➕ Процесс C: Использует 4 ГБ памяти, oom_score = 700

В этом случае, процесс C с наибольшим значением oom_score и использованием памяти будет наиболее вероятным кандидатом для завершения.

Управление поведением

Администраторы могут управлять его поведением, изменяя значения в /proc. Например, можно повысить приоритет критически важного процесса:

echo -1000 > /proc/<critical_process_pid>/oom_score_adj

Или, наоборот, снизить приоритет ненужного процесса:

echo 1000 > /proc/<non_critical_process_pid>/oom_score_adj

OOM Killer используется для завершения процессов при нехватке памяти. Oн выбирает процессы на основе значений oom_score, использования памяти, приоритета процессов и их состояния.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Какой из сигналов SIGTERM / SIGKILL вызывает команда kill ?

💬 Спрашивают в 13% собеседований

Команда kill в Unix и Unix-подобных системах (например, Linux) используется для отправки сигналов процессам. По умолчанию команда kill отправляет сигнал SIGTERM. Сигнал SIGKILL можно отправить явно, указав его как параметр.

Основные сигналы

➕ SIGTERM (сигнал номер 15):

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

➕ SIGKILL (сигнал номер 9):

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

Примеры

Отправка сигнала SIGTERM (по умолчанию):

Когда используется команда kill без указания конкретного сигнала, отправляется сигнал SIGTERM:

kill <PID>

где <PID> — идентификатор процесса, которому отправляется сигнал.

Например:

kill 1234

Отправка сигнала SIGKILL:

Чтобы это сделать, необходимо явно указать его номер (9) или имя (SIGKILL):

kill -9 <PID>

или

kill -SIGKILL <PID>

Например:

kill -9 1234

или

kill -SIGKILL 1234

Различия

1️⃣ SIGTERM:

➕ Процесс может перехватить и обработать сигнал, выполняя очистку и корректное завершение.

➕ Процесс может игнорировать сигнал (если он настроен на это).

➕ Это "вежливый" способ завершения процесса.

2️⃣ SIGKILL:

➕ Процесс не может перехватить, обработать или игнорировать сигнал.

➕ Процесс немедленно завершает работу без возможности выполнения очистки.

➕ Используется в случаях, когда процесс не отвечает на SIGTERM.

Примеры

1️⃣ Отправка сигнала SIGTERM:

kill 1234

Если процесс 1234 настроен на перехват и обработку SIGTERM, он выполнит необходимые операции по завершению и затем завершится. Если процесс не отвечает на SIGTERM, можно использовать SIGKILL.

2️⃣ Отправка сигнала SIGKILL:

kill -9 1234

Процесс 1234 будет немедленно завершен, без возможности выполнения каких-либо операций по завершению.

Команда kill по умолчанию отправляет сигнал SIGTERM, который может быть перехвачен и обработан процессом. Сигнал SIGKILL (отправляемый с помощью kill -9 или kill -SIGKILL) немедленно завершает процесс и не может быть перехвачен или проигнорирован.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что такое хендлеры ?

💬 Спрашивают в 13% собеседований

Хендлеры (handlers) в контексте программирования и системного администрирования представляют собой функции или процедуры, которые отвечают на определенные события или сигналы. Могут использоваться в различных областях, таких как обработка сигналов в операционных системах, обработка событий в графических интерфейсах пользователя (GUI), веб-программировании и автоматизации задач.

1️⃣ Обработка сигналов в Unix/Linux

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

import signal
import time

# Определение хендлера для сигнала SIGTERM
def handle_sigterm(signum, frame):
    print("Received SIGTERM, exiting gracefully...")
    exit(0)

# Регистрация хендлера
signal.signal(signal.SIGTERM, handle_sigterm)

# Бесконечный цикл, который будет прерван сигналом
while True:
    print("Running...")
    time.sleep(1)

2️⃣ Веб-программирование

В нем хендлеры используются для обработки запросов к веб-серверу. В различных фреймворках, таких как Django или Flask, хендлеры определяются для обработки различных маршрутов и методов HTTP.

from flask import Flask, request

app = Flask(__name__)

# Определение хендлера для GET запроса к корневому маршруту
@app.route('/', methods=['GET'])
def handle_root():
    return "Hello, World!"

# Определение хендлера для POST запроса к маршруту /submit
@app.route('/submit', methods=['POST'])
def handle_submit():
    data = request.form['data']
    return f"Received: {data}"

if __name__ == '__main__':
    app.run(debug=True)

3️⃣ Обработка событий в GU

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

import tkinter as tk

# Определение функции-хендлера для нажатия кнопки
def on_button_click():
    print("Button clicked!")

# Создание основного окна
root = tk.Tk()
root.title("Example GUI")

# Создание кнопки и привязка хендлера
button = tk.Button(root, text="Click Me", command=on_button_click)
button.pack()

# Запуск основного цикла приложения
root.mainloop()

Хендлеры

Ansible

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

- name: Ensure nginx is installed and configured
  hosts: webservers
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Copy nginx configuration
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify:
        - Restart nginx

  handlers:
    - name: Restart nginx
      service:
        name: nginx
        state: restarted

Хендлеры — это функции или процедуры, которые обрабатывают определенные события или сигналы в различных контекстах, таких как операционные системы, веб-программирование, графические интерфейсы и автоматизация задач.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что такое системные вызовы и системные сигналы ?

💬 Спрашивают в 13% собеседований

Системные вызовы и системные сигналы являются основными механизмами взаимодействия программного обеспечения с операционной системой в Unix и Unix-подобных системах, таких как Linux. Они обеспечивают доступ к аппаратным и программным ресурсам системы и позволяют управлять различными аспектами работы процессов.

Системные вызовы (system calls)

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

1️⃣ Работа с файлами:

➕ open(): открывает файл.

➕ read(): читает данные из файла.

➕ write(): записывает данные в файл.

➕ close(): закрывает файл.

2️⃣ Управление процессами:

➕ fork(): создает новый процесс путем копирования текущего.

➕ exec(): заменяет текущий процесс новым.

➕ wait(): ожидает завершения дочернего процесса.

➕ exit(): завершает процесс.

3️⃣ Работа с памятью:

➕ mmap(): отображает файл или устройство в память.

➕ munmap(): отменяет отображение памяти.

Пример открытия файла, чтения из него и записи в другой файл с использованием системных вызовов:

#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main() {
    int fd_src, fd_dest;
    char buffer[1024];
    ssize_t bytes_read, bytes_written;

    // Открытие исходного файла
    fd_src = open("source.txt", O_RDONLY);
    if (fd_src < 0) {
        perror("open source.txt");
        exit(EXIT_FAILURE);
    }

    // Открытие (или создание) файла назначения
    fd_dest = open("destination.txt", O_WRONLY | O_CREAT, 0644);
    if (fd_dest < 0) {
        perror("open destination.txt");
        close(fd_src);
        exit(EXIT_FAILURE);
    }

    // Чтение и запись данных
    while ((bytes_read = read(fd_src, buffer, sizeof(buffer))) > 0) {
        bytes_written = write(fd_dest, buffer, bytes_read);
        if (bytes_written != bytes_read) {
            perror("write");
            close(fd_src);
            close(fd_dest);
            exit(EXIT_FAILURE);
        }
    }

    // Закрытие файлов
    close(fd_src);
    close(fd_dest);

    return 0;
}

Системные сигналы (signals)

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

Примеры:

1️⃣ SIGINT (2): прерывание (например, нажатие Ctrl+C).

2️⃣ SIGTERM (15): запрос на завершение процесса.

3️⃣ SIGKILL (9): принудительное завершение процесса (не может быть перехвачен или игнорирован).

Пример программы, которая обрабатывает сигнал SIGINT (Ctrl+C):

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>

void handle_sigint(int sig) {
    printf("Caught signal %d (SIGINT). Exiting...\n", sig);
    exit(0);
}

int main() {
    // Установка обработчика сигнала SIGINT
    signal(SIGINT, handle_sigint);

    // Бесконечный цикл
    while (1) {
        printf("Running...\n");
        sleep(1);
    }

    return 0;
}

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

➕ Системные сигналы — это механизм асинхронного уведомления процессов о различных событиях, таких как ошибки, завершение процессов или пользовательские события.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Чем контейнер отличается от пола ?

💬 Спрашивают в 13% собеседований

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

Основные функции

1️⃣ Управление подами:

➕ Принимает манифесты Pod и гарантирует, что все описанные контейнеры запущены и работают в соответствии с указанными спецификациями. Он периодически проверяет состояние контейнеров и перезапускает их в случае сбоя.

2️⃣ Мониторинг и отчетность:

➕ Собирает информацию о состоянии подов и контейнеров и отправляет эту информацию в основной компонент управления Kubernetes — API Server. Это позволяет отслеживать состояние всей системы и принимать решения о перераспределении ресурсов при необходимости.

3️⃣ Контроль состояния контейнеров:

➕ Использует cAdvisor для сбора метрик о работе контейнеров, таких как использование CPU, памяти и сетевых ресурсов.

4️⃣ Взаимодействие с контейнер-рантаймом:

➕ Взаимодействует с контейнер-рантаймами, такими как Docker, containerd или CRI-O, через Container Runtime Interface (CRI). Это позволяет ему запускать, останавливать и управлять контейнерами.

5️⃣ Обеспечение конфигурации и секретов:

➕ Обеспечивает контейнеры конфигурацией и секретами, необходимыми для их работы, извлекая эти данные из Kubernetes API Server и монтируя их в контейнеры.

6️⃣ Проби здоровья (Liveness, Readiness):

➕ Выполняет проверки здоровья контейнеров, такие как liveness и readiness probes, чтобы определить, являются ли контейнеры здоровыми и готовы ли они обрабатывать запросы. Если контейнер не проходит проверку, Kubelet может перезапустить его.

🤔 Как он работает

1️⃣ Получение спецификации подов:

➕ Получает спецификации подов от API Server. Это может происходить автоматически через систему управления Kubernetes или через локальные манифесты, находящиеся в определенных директориях.

2️⃣ Запуск контейнеров:

➕ Использует контейнер-рантайм для запуска контейнеров в соответствии с полученными спецификациями.

3️⃣ Обновление состояния:

➕ Регулярно обновляет API Server информацией о текущем состоянии подов и контейнеров на узле.

4️⃣ Выполнение проб здоровья:

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

Может быть настроен через командную строку, конфигурационные файлы или параметры, передаваемые при запуске. Пример конфигурационного файла Kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
readOnlyPort: 10255
cgroupDriver: cgroupfs
clusterDNS:
  - 10.96.0.10
clusterDomain: cluster.local
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: "/etc/kubernetes/pki/ca.crt"
authorization:
  mode: Webhook

Kubelet — это агент, который работает на каждом узле кластера Kubernetes и отвечает за запуск, мониторинг и управление контейнерами в подах. Он взаимодействует с контейнер-рантаймом, выполняет проверки здоровья контейнеров и отправляет информацию о состоянии подов в API Server.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что за компонент kubelet ?

💬 Спрашивают в 13% собеседований

Kubelet — это один из ключевых компонентов Kubernetes, который работает на каждом узле кластера и отвечает за управление подами (pods) и контейнерами на этом узле. Он действует как агент, обеспечивая выполнение и поддержание заданного состояния контейнеров.

Основные функции

1️⃣ Управление подами:

➕ Принимает спецификации подов (PodSpecs) от Kubernetes API Server и гарантирует, что все описанные контейнеры запущены и работают в соответствии с указанными спецификациями. Он следит за состоянием подов и перезапускает контейнеры в случае их сбоя.

2️⃣ Мониторинг и отчетность:

➕ Собирает информацию о состоянии подов и контейнеров и отправляет эту информацию в API Server. Это помогает центральной системе управления Kubernetes отслеживать состояние всего кластера и принимать решения о перераспределении ресурсов при необходимости.

3️⃣ Интеграция с контейнер-рантаймом:

➕ Взаимодействует с контейнер-рантаймами (например, Docker, containerd или CRI-O) через интерфейс Container Runtime Interface (CRI). Это позволяет Kubelet запускать, останавливать и управлять контейнерами.

4️⃣ Проби здоровья (Liveness, Readiness):

➕ Выполняет проверки здоровья контейнеров (liveness и readiness probes), чтобы определить, являются ли контейнеры здоровыми и готовы ли они обрабатывать запросы. Если контейнер не проходит проверку, Kubelet может перезапустить его или принять другие меры.

5️⃣ Обеспечение конфигурации и секретов:

➕ Монтирует конфигурации и секреты (config maps и secrets), необходимые для работы контейнеров, извлекая их из Kubernetes API Server и предоставляя их контейнерам.

6️⃣ Логи и метрики:

➕ Собирает логи и метрики о работе контейнеров и узла в целом. Эти данные могут использоваться для мониторинга и диагностики.

🤔 Как он работает

1️⃣ Получение спецификации подов:

➕ Получает спецификации подов от API Server. Это может происходить автоматически через систему управления Kubernetes или через локальные манифесты, находящиеся в определенных директориях на узле.

2️⃣ Запуск и управление контейнерами:

➕ Использует контейнер-рантайм для запуска контейнеров в соответствии с полученными спецификациями.

3️⃣ Мониторинг и обновление состояния:

➕ Регулярно обновляет API Server информацией о текущем состоянии подов и контейнеров на узле. Он также выполняет регулярные проверки состояния контейнеров (probes) и принимает меры в случае обнаружения проблем.

Может быть настроен через конфигурационные файлы или параметры командной строки. Пример конфигурационного файла Kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
readOnlyPort: 10255
cgroupDriver: cgroupfs
clusterDNS:
  - 10.96.0.10
clusterDomain: cluster.local
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: "/etc/kubernetes/pki/ca.crt"
authorization:
  mode: Webhook

Взаимодействие с другими компонентами Kubernetes

➕ API Server: Взаимодействует с API Server для получения спецификаций подов и отправки отчетов о состоянии.

➕ Scheduler: Scheduler назначает поды на узлы, где работает Kubelet, который затем управляет этими подами.

➕ Controller Manager: Взаимодействует с контроллерами, обеспечивая реализацию различных политик и управляя состоянием подов.

Kubelet — это агент на каждом узле кластера Kubernetes, который управляет подами и контейнерами, следит за их состоянием, взаимодействует с контейнер-рантаймами и обеспечивает выполнение всех необходимых операций для поддержания корректной работы подов.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 В чем заключается роль DevOps \SRE\IE ?

💬 Спрашивают в 13% собеседований

Роль DevOps (Development Operations), SRE (Site Reliability Engineering) и IE (Infrastructure Engineering) в современном IT заключается в обеспечении надежности, эффективности и масштабируемости разработки, развертывания и поддержки программного обеспечения. Давайте рассмотрим каждую из этих ролей подробнее.

DevOps

Это методология и культура, направленная на тесное сотрудничество между командами разработки (Dev) и эксплуатации (Ops). Цели:

1️⃣ Ускорение разработки и развертывания ПО: Автоматизация CI/CD (Continuous Integration/Continuous Deployment) процессов позволяет быстрее и чаще выпускать новые версии приложений.

2️⃣ Повышение качества и стабильности ПО: Автоматизация тестирования и мониторинга помогает обнаруживать и исправлять ошибки на ранних этапах.

3️⃣ Улучшение взаимодействия между командами: Внедрение общих инструментов и процессов способствует лучшему пониманию и сотрудничеству.

stages:
  - build
  - test
  - deploy

build:
  script:
    - ./build.sh

test:
  script:
    - ./run_tests.sh

deploy:
  script:
    - ./deploy.sh

Этот скрипт описывает этапы сборки, тестирования и развертывания приложения.

SRE

Это подход, разработанный в Google, который фокусируется на обеспечении надежности и стабильности сервисов. Задачи:

1️⃣ Мониторинг и оповещение: Использование инструментов мониторинга для отслеживания состояния системы и отправки оповещений при сбоях.

2️⃣ Автоматизация и улучшение процессов: Постоянное улучшение существующих процессов и автоматизация рутинных задач.

3️⃣ Управление инцидентами: Быстрое реагирование на инциденты и их последующее расследование для предотвращения повторения.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'my_application'
    static_configs:
      - targets: ['localhost:9090']

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

IE

Это инженерия инфраструктуры, которая отвечает за проектирование, развертывание и поддержку базовой инфраструктуры для приложений. Основные задачи IE:

1️⃣ Проектирование и развертывание инфраструктуры: Создание масштабируемой и надежной инфраструктуры, например, с использованием облачных сервисов.

2️⃣ Автоматизация инфраструктуры: Использование IaC (Infrastructure as Code) для автоматического развертывания и управления инфраструктурой.

3️⃣ Обеспечение безопасности и соответствия: Поддержание высокого уровня безопасности и соответствие нормативным требованиям.

provider "aws" {
  region = "us-west-2"
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "example-instance"
  }
}

Этот скрипт создает виртуальную машину в облаке AWS.

DevOps улучшает взаимодействие и автоматизирует процессы разработки и эксплуатации. SRE фокусируется на надежности и стабильности сервисов. IE проектирует и управляет инфраструктурой для приложений.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Чем gitlab ci артефакты отличаются от кэша как атрибуты джобы ?

💬 Спрашивают в 13% собеседований

Артефакты и кэш в GitLab CI/CD выполняют разные функции и используются для различных целей в контексте выполнения джоб (jobs).

🤔 Артефакты (Artifacts)

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

🤔 Основные характеристики:

1️⃣ Сохранение результатов: Сохраняются выходные файлы, созданные в ходе выполнения джобы (например, собранные бинарные файлы, отчеты о тестировании).

2️⃣ Временное хранение: Хранятся ограниченное время (по умолчанию 30 дней, но можно настроить).

3️⃣ Доступ между джобами: Могут быть переданы между различными джобами в рамках одного pipeline.

4️⃣ Скачивание артефактов: Могут быть загружены пользователями через интерфейс GitLab.

build:
  stage: build
  script:
    - make build
  artifacts:
    paths:
      - build/
    expire_in: 1 week

В этом примере выходные файлы, созданные в директории build/, сохраняются как артефакты и хранятся в течение одной недели.

🤔 Кэш (Cache)

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

🤔 Основные характеристики:

1️⃣ Повторное использование данных: Предназначен для хранения данных, которые могут использоваться повторно в разных сборках.

2️⃣ Снижение времени сборки: Помогает ускорить сборку, избегая повторной загрузки и сборки неизменных зависимостей.

3️⃣ Глобальный кэш: Кэш может использоваться несколькими джобами и даже различными пайплайнами.

4️⃣ Конфигурация ключей: Можно настроить ключи для управления, когда кэш должен быть обновлен или использован.

cache:
  paths:
    - node_modules/

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

🤔 Отличия

1️⃣ Назначение:

➕ Артефакты: Хранят выходные данные джобы для последующего использования или анализа.

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

2️⃣ Срок хранения:

➕ Артефакты: Хранятся временно и удаляются по истечении срока (настраиваемого).

➕ Кэш: Может быть перезаписан или сохранен до тех пор, пока не изменятся ключи кэша.

3️⃣ Доступ:

➕ Артефакты: Могут быть скачаны пользователями и доступны для других джоб в рамках одного пайплайна.

➕ Кэш: Обычно используется только для ускорения процесса сборки и не предназначен для загрузки пользователями.

Артефакты сохраняют выходные данные джоб для использования в других джобах или анализа. Кэш хранит промежуточные данные для ускорения будущих сборок.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 В чём основное преимущество systemd ?

💬 Спрашивают в 13% собеседований

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

1️⃣ Параллельная загрузка служб

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

systemctl list-jobs

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

2️⃣ Управление зависимостями

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

[Unit]
Description=My Service
After=network.target

[Service]
ExecStart=/usr/bin/my_service

[Install]
WantedBy=multi-user.target

Здесь указано, что служба my_service должна запускаться после network.target.

3️⃣ Унифицированное управление

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

systemctl start my_service
systemctl stop my_service
systemctl status my_service

4️⃣ Логирование и диагностика

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

journalctl -u my_service

Эта команда выводит логи конкретной службы my_service.

5️⃣ Снимки и восстановление состояния

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

systemctl snapshot my_snapshot
systemctl isolate my_snapshot

6️⃣ Контроль ресурсов

Интегрирован с cgroups (control groups), что позволяет управлять и ограничивать ресурсы (CPU, память и т.д.) для отдельных служб и процессов.

[Service]
CPUQuota=20%
MemoryLimit=500M

Этот конфигурационный файл ограничивает использование CPU до 20% и памяти до 500 МБ для конкретной службы.

7️⃣ Тайм-ауты и рестарт

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

[Service]
Restart=on-failure
TimeoutStartSec=30
TimeoutStopSec=30

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

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что хранится в etc fstab ?

💬 Спрашивают в 13% собеседований

Файл /etc/fstab (file system table) содержит информацию о файловых системах и устройствах, которые должны быть автоматически смонтированы при загрузке системы или вручную пользователем. Этот файл используется системными утилитами и скриптами для монтирования файловых систем.

🤔 Основные элементы файла /etc/fstab

Каждая строка в /etc/fstab описывает одну файловую систему и состоит из шести полей:

1️⃣ Устройство (Device): Указывает устройство или раздел, который будет смонтирован. Это может быть идентификатор устройства (например, /dev/sda1), UUID (уникальный идентификатор устройства) или метка устройства (label).

➕ /dev/sda1

➕ UUID=123e4567-e89b-12d3-a456-426614174000

➕ LABEL=mydisk

2️⃣ Точка монтирования (Mount Point): Указывает, куда файловая система будет смонтирована в файловой системе. Это может быть, например, корневая файловая система (/), домашний каталог (/home) или специальный каталог для временных файлов (/tmp).

➕ /

➕ /home

➕ /mnt/mydisk

3️⃣ Тип файловой системы (File System Type): Указывает тип файловой системы, который будет использован для монтирования. Примеры файловых систем включают ext4, xfs, ntfs, swap и vfat.

➕ ext4

➕ xfs

➕ ntfs

4️⃣ Параметры монтирования (Mount Options): Указывает параметры монтирования, которые определяют, как файловая система будет смонтирована. Эти параметры включают в себя такие опции, как defaults, ro (read-only), rw (read-write), noexec (запрещение выполнения файлов) и другие.

➕ defaults

➕ noatime

➕ ro

5️⃣ Параметр дампа (Dump): Указывает, следует ли выполнять резервное копирование этой файловой системы утилитой dump. Значение 0 означает, что резервное копирование не требуется, а 1 означает, что необходимо включить файловую систему в дамп.

➕ 0

➕ 1

6️⃣ Параметр проверки файловой системы (Fsck Order): Указывает порядок проверки файловых систем при загрузке с помощью утилиты fsck. Значение 0 означает, что проверка не требуется, 1 указывает на корневую файловую систему, а 2 и более — на другие файловые системы, которые должны быть проверены после корневой.

🤔 Пример файла /etc/fstab

# <файл устройства>       <точка монтирования> <тип файловой системы> <параметры>     <дамп> <порядок проверки>
UUID=123e4567-e89b-12d3-a456-426614174000 /                       ext4    defaults        1       1
/dev/sda2              /home                ext4    defaults        0       2
/dev/sdb1              /mnt/storage         ext4    defaults,noatime 0     2
/dev/sdc1              swap                 swap    defaults        0       0

🤔 В этом примере:

➕ Первая строка монтирует корневую файловую систему (/) с типом ext4 и стандартными параметрами, и указывает, что она должна быть проверена первой.

➕ Вторая строка монтирует раздел /dev/sda2 в каталог /home с типом ext4 и стандартными параметрами.

➕ Третья строка монтирует раздел /dev/sdb1 в каталог /mnt/storage с типом ext4 и дополнительным параметром noatime, который отключает обновление временных меток доступа.

➕ Четвертая строка указывает на использование раздела /dev/sdc1 в качестве подкачки (swap).

Файл /etc/fstab хранит информацию о файловых системах и их параметрах монтирования, используемых для автоматического или ручного монтирования устройств в систему.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Как работает https ?

💬 Спрашивают в 13% собеседований

HTTPS (HyperText Transfer Protocol Secure) — это расширение HTTP (HyperText Transfer Protocol), которое используется для безопасной передачи данных по сети. Основное отличие HTTPS от HTTP заключается в том, что HTTPS использует SSL/TLS (Secure Sockets Layer / Transport Layer Security) для шифрования данных, что обеспечивает конфиденциальность и целостность передаваемой информации.

🤔 Как он работает

1️⃣ Установление соединения (TLS Handshake):

➕ Инициирование соединения: Клиент (например, веб-браузер) отправляет запрос на сервер с целью установления защищенного соединения. Этот запрос включает информацию о версиях TLS, которые поддерживает клиент, и о криптографических алгоритмах, которые он может использовать.

➕ Ответ сервера: Сервер отвечает, указывая выбранную версию TLS и криптографический алгоритм. Он также отправляет свой цифровой сертификат, который содержит публичный ключ сервера и подтвержден сертификационным центром (CA - Certificate Authority).

2️⃣ Проверка сертификата:

➕ Проверка подлинности: Клиент проверяет сертификат сервера с помощью сертификационного центра. Если сертификат действителен и доверен, клиент продолжает процесс. В противном случае клиент может показать предупреждение пользователю о возможной небезопасности соединения.

3️⃣ Генерация сессионных ключей:

➕ Обмен ключами: Клиент и сервер договариваются о секретном ключе, который будет использоваться для шифрования данных в течение сессии. Обычно это происходит с помощью асимметричного шифрования: клиент шифрует сессионный ключ публичным ключом сервера и отправляет его серверу. Сервер расшифровывает его своим приватным ключом.

4️⃣ Установление защищенного канала:

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

5️⃣ Передача данных:

➕ Безопасное общение: Все данные, передаваемые между клиентом и сервером, зашифрованы сессионным ключом. Это защищает данные от перехвата и изменения.

6️⃣ Завершение сессии:

➕ Закрытие соединения: После завершения обмена данными клиент и сервер закрывают соединение, удаляя сессионные ключи.

Компоненты HTTPS

1️⃣ Цифровой сертификат:

➕ Цифровой сертификат используется для проверки подлинности сервера. Он выдается сертификационным центром и содержит публичный ключ сервера и информацию о его владельце.

2️⃣ SSL/TLS протоколы:

➕ SSL (Secure Sockets Layer) и его более современный вариант TLS (Transport Layer Security) обеспечивают шифрование данных. TLS более безопасен и рекомендуется для использования вместо SSL.

3️⃣ Асимметричное и симметричное шифрование:

➕ Асимметричное шифрование (с использованием публичного и приватного ключей) используется для безопасного обмена сессионными ключами.

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

1️⃣ Пользователь вводит URL-адрес в браузере, начинающийся с https://.

2️⃣ Браузер отправляет запрос на сервер для установления защищенного соединения.

3️⃣ Сервер отвечает, отправляя свой цифровой сертификат.

4️⃣ Браузер проверяет сертификат с помощью сертификационного центра.

5️⃣ Если сертификат действителен, браузер и сервер договариваются о сессионном ключе.

6️⃣ Все данные, передаваемые между браузером и сервером, шифруются сессионным ключом.

7️⃣ После завершения обмена данными соединение закрывается.

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Зачем нужен inode ?

💬 Спрашивают в 13% собеседований

Inode (index node) — это структура данных в файловых системах Unix и Unix-подобных системах (например, Linux), которая хранит информацию о файлах и каталогах, за исключением их имен и содержимого. Каждому файлу или каталогу в файловой системе соответствует свой уникальный inode.

🤔 Зачем он нужен?

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

Основные функции и информация:

1️⃣ Метаданные файла:

➕ Идентификатор владельца (UID): Указывает, кто является владельцем файла.

➕ Идентификатор группы (GID): Указывает группу, к которой принадлежит файл.

➕ Права доступа (permissions): Определяет, кто может читать, записывать или выполнять файл.

➕ Тип файла: Указывает, является ли файл обычным файлом, каталогом, символической ссылкой, устройством и т.д.

➕ Размер файла: Указывает размер файла в байтах.

Временные метки:

➕ ctime (Change time): Время последнего изменения метаданных файла.

➕ mtime (Modification time): Время последнего изменения содержимого файла.

➕ atime (Access time): Время последнего доступа к файлу.

2️⃣ Указатели на блоки данных:

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

3️⃣ Счетчик ссылок (link count):

➕ Указывает количество жестких ссылок на данный inode, то есть количество имен, связанных с этим файлом.

🤔 Как это работает

Когда создается файл, файловая система выделяет inode и один или несколько блоков для хранения данных файла. Inode хранит всю информацию о файле, кроме его имени и содержимого. Имя файла хранится в каталоге, который содержит сопоставление имен файлов с их inodes.

1️⃣ Создание файла:

➕ При создании нового файла система выделяет новый inode и записывает в него всю необходимую метаинформацию о файле.

2️⃣ Доступ к файлу:

➕ При доступе к файлу система сначала ищет его имя в каталоге, чтобы найти соответствующий inode. Затем она использует inode для получения информации о файле и его содержимом.

3️⃣ Удаление файла:

➕ При удалении файла система уменьшает счетчик ссылок в inode. Если счетчик ссылок достигает нуля, inode и все блоки данных, связанные с файлом, освобождаются.

Команда ls -i показывает номер inode для каждого файла в каталоге:

ls -i

Пример вывода:

1234567 file1.txt
1234568 file2.txt
1234569 directory1

Здесь 1234567, 1234568 и 1234569 — номера inodes для file1.txt, file2.txt и directory1 соответственно.

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

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых