Архив автора: admin

Основы геометрического ядра

Геометрическое ядро — встраиваемая в CAD разработчиком программа для создания и редактирования моделей 2D и 3D, база для дальнейшего моделирования, движок или геометрическая библиотека с основными математическими функциями CAD-системы. При помощи ядра осуществляется моделирование твердотельных, поверхностных и каркасных объектов, определяются, преобразуются и запоминаются элементы 3D-моделей, визуализируются проектируемые объекты.

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

Лицензируемое ядро принадлежит компании-разработчику ПО, которая продает лицензию на использование и предоставляет поддержку. Частные ядра создавались только для конкретных приложений разработчиков САПР, тесно интегрировались с интерфейсами CAD-приложений, функционально соответствовали потребностям создателей. Ядра с открытым кодом создаются одной компанией и лицензируются другими по исходному коду. Пользователи могут вносить необходимые изменения в программу.

 

Зарубежные и отечественные геометрические ядра

Современные CAD-приложения разрабатывают на геометрических ядрах:

  •       Parasolid, ACIS (USA);

  •       Open CASCADE Technology (Франция);

  •       С3D Modeler, РГЯ (Россия).

 

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

Ядро характеризуется выполнением всех необходимых расчетов, поддержкой граничного и полигонального представления моделей, удобством редактирования, качественной визуализацией. На базе С3D Modeler созданы многочисленные программные решения для коммерческих и производственных компаний. Стоимость лицензии включает годовую подписку с обновлениями и техподдержкой и отчисления с продаж ПО, разработанного с применением этого компонента. Годовая лицензия обходится подписчикам в сумму 720 тыс. руб.



2023-04-04T13:43:12
Программное обеспечение

👥 Как создавать многострочные комментарии в shell скриптах

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

Комментарии в скриптах bash обозначаются символом хэша (#).

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

В этой статье мы рассмотрим, как создавать многострочные комментарии в сценарии оболочки.

Метод 1: Использование нескольких однострочных комментариев

Одним из способов создания многострочных комментариев в скриптах является использование нескольких однострочных комментариев.

Для этого в каждой строке используется хэш-символ (#), за которым следует текст комментария.

Вот пример:

#!/bin/bash



# Это многострочный комментарий

# который охватывает несколько строк

# и объясняет цель скрипта



echo "Hello, world!"

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

Метод 2: Использование HereDoc

Другой способ создания многострочных комментариев в скриптах – это использование Here Documents.

Here Documents – это способ включить несколько строк текста в скрипт.

Вот пример:

#!/bin/bash



: <<'COMMENT'

Это многострочный комментарий

который охватывает несколько строк

и объясняет цель скрипта

COMMENT



echo "Hello, world!"

В этом примере мы используем Here Document для создания многострочного комментария, который занимает три строки.

Синтаксис Here-документа следующий : <<‘STRING’, где STRING – это разделитель, который отмечает конец Here-документа.

В данном случае мы используем COMMENT в качестве разделителя.

Метод 3: Использование команды :

Наконец, вы можете создавать многострочные комментарии в сценарии оболочки с помощью команды :.

Команда : – это команда, которая ничего не делает, но ее можно использовать для создания многострочного комментария.

Вот пример:

#!/bin/bash

: '

Это многострочный комментарий 

который охватывает несколько строк

и объясняет цель скрипта

'

echo "Hello, world!"

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

Текст комментария заключен в одинарные кавычки.

Заключение

Комментарии являются важной частью написания скриптов, поскольку они помогают объяснить цель и функции кода.

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

Независимо от того, предпочитаете ли вы использовать несколько однострочных комментариев, Here Documents или команду :, эти методы помогут вам писать четкие и лаконичные комментарии в shell скриптах.

см. также:



2023-04-04T12:39:38
Скрипты

Sage: веб-платформа с искусственным интеллектом для использования чат-ботов в Linux.

Sage: веб-платформа с искусственным интеллектом для использования чат-ботов в Linux.

Sage: веб-платформа с искусственным интеллектом для использования чат-ботов в Linux.

Учитывая, что в настоящее время одним из наиболее актуальных ИТ-трендов является использование онлайн-сервисы искусственного интеллекта, в виде чат-ботов, в основном для выполнения многих личных, профессиональных или деловых задач, здесь, на DesdeLinuxПонемногу мы сообщаем о некоторых из них. Прежде всего те, которые основаны на бесплатных или открытых технологиях или, по крайней мере, бесплатны и просты в использовании.

По этой причине мы использовали OpenAI ChatGPT и некоторые настольные клиенты для него, Bard от Google, LLaMa от Facebook, Bing Chat от Microsoft и другие, такие как Merlin, Translaite и ChacarterAI. Принимая во внимание, что сегодня мы обратимся к веб-платформе Poe с ее сервисом чат-ботов с искусственным интеллектом, который называется «Мудрец», который на данный момент является простым, бесплатным и бесплатным для регистрации. С помощью которого мы можем легко создать веб-приложение для использования в наших дистрибутивах GNU/Linux или других операционных системах. Так же, как в предыдущем случае, мы учили, как делать Веб-приложение MilagrOS AI с CharacterAI.



Читать →

MusicPod: Интересный проигрыватель музыки, радио и подкастов.

MusicPod: Интересный проигрыватель музыки, радио и подкастов.

MusicPod: Интересный проигрыватель музыки, радио и подкастов.

На протяжении многих лет у нас DesdeLinux пересмотрела хороший процент огромное количество мультимедийных приложений, бесплатное и открытое, связанное с плеерами, как музыкой, так и онлайн-радио и подкастами. Некоторые из них очень старые, много лет в экосистеме, а другие относительно новые, с доступностью всего пару лет. Но сегодня мы обратимся к очень недавнему, доступному всего несколько месяцев, который называется «МьюзикПод».

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



Читать →

Kubernetes — Автоскейлинг приложений при помощи Prometheus и KEDA

Kubernetes позволяет автоматически масштабировать приложения (то есть Pod в развертывании или ReplicaSet) декларативным образом с использованием спецификации Horizontal Pod Autoscaler.




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




Вместо горизонтального автомасштабирования подов, применяется Kubernetes Event Driven Autoscaling (KEDA) — оператор Kubernetes с открытым исходным кодом. Он изначально интегрируется с Horizontal Pod Autoscaler, чтобы обеспечить плавное автомасштабирование (в том числе до/от нуля) для управляемых событиями рабочих нагрузок. Код доступен на GitHub.




Краткий обзор работы системы





На схеме — краткое описание того, как все работает:




  1. Приложение предоставляет метрики количества обращений к HTTP в формате Prometheus.




  2. Prometheus настроен на сбор этих показателей.




  3. Скейлер Prometheus в KEDA настроен на автоматическое масштабирование приложения на основе количества обращений к HTTP.




Теперь подробно расскажу о каждом элементе.




KEDA и Prometheus




Prometheus — набор инструментов для мониторинга и оповещения систем с открытым исходным кодом, часть Cloud Native Computing Foundation. Собирает метрики из разных источников и сохраняет в виде данных временных рядов. Для визуализации данных можно использовать Grafana или другие инструменты визуализации, работающие с API Kubernetes.




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




Скейлеры поддерживают нескольких источников данных, например, Kafka, Redis, Prometheus. То есть KEDA можно применять для автоматического масштабирования развертываний Kubernetes, используя в качестве критериев метрики Prometheus.




KEDA Prometheus ScaledObject




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




ScaledObject содержит информацию о масштабировании развертывания, метаданные об источнике события (например, секреты для подключения, имя очереди), интервал опроса, период восстановления и другие данные. Он приводит к соответствующему ресурсу автомасштабирования (определение HPA) для масштабирования развертывания.




Когда объект ScaledObject удаляется, соответствующее ему определение HPA очищается.




Вот определение ScaledObject для нашего примера, в нем используется скейлер Prometheus:




apiVersion: keda.k8s.io/v1alpha1

kind: ScaledObject

metadata:

 name: prometheus-scaledobject

 namespace: default

 labels:

  deploymentName: go-prom-app

spec:

 scaleTargetRef:

   deploymentName: go-prom-app

 pollingInterval: 15

 cooldownPeriod:  30

 minReplicaCount: 1

 maxReplicaCount: 10

 triggers:

 - type: prometheus

  metadata:

    serverAddress:

http://prometheus-service.default.svc.cluster.local:9090

    metricName: access_frequency

    threshold: '3'

    query: sum(rate(http_requests[2m]))




Учтите следующие моменты:




  1. Он указывает на Deployment с именем go-prom-app.




  2. Тип триггера — Prometheus. Адрес сервера Prometheus упоминается вместе с именем метрики, пороговым значением и запросом PromQL, который будет использоваться. Запрос PromQL — sum(rate(http_requests[2m])).




  3. Согласно pollingInterval, KEDA запрашивает цель у Prometheus каждые пятнадцать секунд. Поддерживается минимум один под (minReplicaCount), а максимальное количество подов не превышает maxReplicaCount (в данном примере — десять).




Можно установить minReplicaCount равным нулю. В этом случае KEDA активирует развертывание с нуля до единицы, а затем предоставляет HPA для дальнейшего автоматического масштабирования. Возможен и обратный порядок, то есть масштабирование от единицы до нуля. В примере мы не выбрали ноль, поскольку это HTTP-сервис, а не система по запросу.




Магия внутри автомасштабирования




Пороговое значение используют в качестве триггера для масштабирования развертывания. В нашем примере запрос PromQL sum(rate (http_requests [2m])) возвращает агрегированное значение скорости HTTP-запросов (количество запросов в секунду), ее измеряют за последние две минуты.




Поскольку пороговое значение равно трем, значит, будет один под, пока значение sum(rate (http_requests [2m])) меньше трех. Если же значение возрастает, добавляется дополнительный под каждый раз, когда sum(rate (http_requests [2m])) увеличивается на три. Например, если значение от 12 до 14, то количество подов — четыре.




Теперь давайте попробуем настроить!




Установка KEDA




Вы можете развернуть KEDA несколькими способами, они перечислены в документации. Я использую монолитный YAML:




[root@kub-master-1 ~]# wget https://github.com/kedacore/keda/releases/download/v2.1.0/keda-2.1.0.yaml
[root@kub-master-1 ~]# kubectl apply -f keda-2.1.0.yaml




ну или можно установить через helm




helm repo add kedacore https://kedacore.github.io/charts
helm repo update
kubectl create namespace keda
helm install keda kedacore/keda —namespace keda




я ставил через монолитный файл.
проверим что всё поднялось:




[root@kub-master-1 ~]# kubectl get all -n keda

NAME                                          READY   STATUS    RESTARTS   AGE

pod/keda-metrics-apiserver-57cbdb849f-w7rfg   1/1     Running   0          70m

pod/keda-operator-58cb545446-5rblj            1/1     Running   0          70m



NAME                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE

service/keda-metrics-apiserver   ClusterIP   10.100.134.31   <none>        443/TCP,80/TCP   70m



NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE

deployment.apps/keda-metrics-apiserver   1/1     1            1           70m

deployment.apps/keda-operator            1/1     1            1           70m



NAME                                                DESIRED   CURRENT   READY   AGE

replicaset.apps/keda-metrics-apiserver-57cbdb849f   1         1         1       70m

replicaset.apps/keda-operator-58cb545446            1         1         1       70m




3. Пример работы




создаём namespace




kubectl create ns my-site




запускаем обычное приложение например apache:




[root@kub-master-1 ~]# cat my-site.yaml




---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: my-deployment-apache

  namespace: my-site

spec:

  replicas: 1

  selector:

    matchLabels:

      app: apache # по вот этому лейблу репликасет цепляет под

# тут описывается каким мокаром следует обновлять поды

  strategy:

    rollingUpdate:

      maxSurge: 1  # указывает на какое количество реплик можно увеличить

      maxUnavailable: 1 # указывает на какое количество реплик можно уменьшить

#т.е. в одно время при обновлении, будет увеличено на один (новый под) и уменьшено на один (старый под)

    type: RollingUpdate

## тут начинается описание контейнера

  template:

    metadata:

      labels:

        app: apache  # по вот этому лейблу репликасет цепляет под

    spec:

      containers:

        - image: httpd:2.4.43

          name: apache

          ports:

            - containerPort: 80

# тут начинаются проверки по доступности

          readinessProbe: # проверка готово ли приложение

            failureThreshold: 3 #указывает количество провалов при проверке

            httpGet:  # по сути дёргает курлом на 80 порт

              path: /

              port: 80

            periodSeconds: 10 #как часто должна проходить проверка (в секундах)

            successThreshold: 1 #сбрасывает счётчик неудач, т.е. при 3х проверках если 1 раз успешно прошло, то счётчик сбрасывается и всё ок

            timeoutSeconds: 1 #таймаут на выполнение пробы 1 секунда

          livenessProbe: #проверка на жизнь приложения, живо ли оно

            failureThreshold: 3

            httpGet:

              path: /

              port: 80

            periodSeconds: 10

            successThreshold: 1

            timeoutSeconds: 1

            initialDelaySeconds: 10 #означает что первую проверку надо сделать только после 10 секунд



# тут начинается описание лимитов для пода

          resources:

            requests: #количество ресурсов которые резервируются для pod на ноде

              cpu: 60m

              memory: 200Mi

            limits: #количество ресурсов которые pod может использовать(верхняя граница)

              cpu: 120m

              memory: 300Mi




[root@kub-master-1 ~]# cat my-site-service.yaml




---

apiVersion: v1

kind: Service

metadata:

  name: my-service-apache # имя сервиса

  namespace: my-site

spec:

  ports:

  - port: 80  # принимать на 80

    targetPort: 80 # отправлять на 80

  selector:

    app: apache  #отправлять на все поды с данным лейблом

  type: ClusterIP




[root@kub-master-1 ~]# cat my-site-ingress.yaml




---

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: my-ingress

  namespace: my-site

spec:

  rules:

  - host: test.ru  #тут указывается наш домен

    http:

      paths:  #список путей которые хотим обслуживать(он дефолтный и все запросы будут отпаврляться на бэкенд, т.е. на сервис my-service-apache)

      - backend:

          serviceName: my-service-apache  #тут указывается наш сервис 

          servicePort: 80 #порт на котором сервис слушает

#        path: /  все запросы на корень '/' будут уходить на наш сервис




применяем:




[root@kub-master-1 ~]# kubectl apply -f my-site.yaml -f my-site-service.yaml -f my-site-ingress.yaml




проверяем:




[root@kub-worker-1 ~]# curl test.ru
<html><body><h1>It works!</h1></body></html>




[root@kub-master-1 ~]# kubectl get all -n my-site




NAME                                        READY   STATUS    RESTARTS   AGE

pod/my-deployment-apache-859486bd8c-k6bql   1/1     Running   0          20m



NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE

service/my-service-apache   ClusterIP   10.100.255.190   <none>        80/TCP    20m



NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE

deployment.apps/my-deployment-apache   1/1     1            1           20m



NAME                                              DESIRED   CURRENT   READY   AGE

replicaset.apps/my-deployment-apache-859486bd8c   1         1         1       20m




будем автоскейлить — для примера по метрике nginx nginx_ingress_controller_requests




запрос в prometheus будет следующий:




sum(irate( nginx_ingress_controller_requests{namespace=»my-site»}[3m] )) by (ingress)*10




т.е. считаем общее количество запросов в неймспейс my-site за 3 минуты




создаём keda сущность:




[root@kub-master-1 ~]# cat hpa-keda.yaml




apiVersion: keda.sh/v1alpha1

kind: ScaledObject

metadata:

  name: prometheus-scaledobject

  namespace: my-site

spec:

  scaleTargetRef:

    name: my-deployment-apache

  minReplicaCount: 1   # Optional. Default: 0

  maxReplicaCount: 8 # Optional. Default: 100

  triggers:

  - type: prometheus

    metadata:

      serverAddress: http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090

      metricName: nginx_ingress_controller_requests

      threshold: '100'

      query: sum(irate(nginx_ingress_controller_requests{namespace="my-site"}[3m])) by (ingress)*10




тут мы указываем в каком namespace нам запускаться:
namespace: my-site




указываем цель, т.е. наш deployment:
name: my-deployment-apache




задаём минимальное и максимальное количество реплик
minReplicaCount: 1 # значение по умолчанию: 0
maxReplicaCount: 8 # значение по умолчанию: 100




есть ещё 2 стандартные переменные отвечающие за то когда поды будут подыматься и убиваться:
pollingInterval: 30 # Optional. Default: 30 seconds
cooldownPeriod: 300 # Optional. Default: 300 seconds




указываем адрес нашего prometheus




serverAddress: http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090
адрес идёт в виде сервис.неймспейс.svc.имя_кластера




указываем нашу метрику:
metricName: nginx_ingress_controller_requests




указываем пороговое значение при котором начнётся автоскейлинг:
threshold: ‘100’




и соответственно наш запрос в prometheus:
query:




всё можно применять:




[root@kub-master-1 ~]# kubectl apply -f hpa-keda.yaml




проверяем:




[root@kub-master-1 ~]# kubectl get horizontalpodautoscalers.autoscaling -n my-site

NAME                               REFERENCE                         TARGETS       MINPODS   MAXPODS   REPLICAS   AGE

keda-hpa-prometheus-scaledobject   Deployment/my-deployment-apache   0/100 (avg)   1         8         1          68m






[root@kub-master-1 ~]# kubectl get pod -n my-site

NAME                                    READY   STATUS    RESTARTS   AGE

my-deployment-apache-859486bd8c-v59b8   1/1     Running   0          37m




а теперь накрутим запросов:




[root@kub-worker-1 ~]# for i in {1..5000}; do curl test.ru; done




проверяем:




[root@kub-master-1 ~]# kubectl get horizontalpodautoscalers.autoscaling -n my-site

NAME                               REFERENCE                         TARGETS            MINPODS   MAXPODS   REPLICAS   AGE

keda-hpa-prometheus-scaledobject   Deployment/my-deployment-apache   34858m/100 (avg)   1         8         7          71m




как видим количество запросов превысило наш лимит и стали создаваться новые поды:




[root@kub-master-1 ~]# kubectl get pod -n my-site

NAME                                    READY   STATUS    RESTARTS   AGE

my-deployment-apache-859486bd8c-6885f   1/1     Running   0          49s

my-deployment-apache-859486bd8c-6mcq4   1/1     Running   0          64s

my-deployment-apache-859486bd8c-cdb6z   1/1     Running   0          64s

my-deployment-apache-859486bd8c-kpwb8   1/1     Running   0          64s

my-deployment-apache-859486bd8c-rmw8d   1/1     Running   0          49s

my-deployment-apache-859486bd8c-v59b8   1/1     Running   0          39m

my-deployment-apache-859486bd8c-xmv28   1/1     Running   0          49s




прекращаем запросы и спустя 5 минут, указанное в переменной cooldownPeriod ненужные поды будут убиты:




[root@kub-master-1 ~]# kubectl get pod -n my-site

NAME                                    READY   STATUS        RESTARTS   AGE

my-deployment-apache-859486bd8c-6885f   0/1     Terminating   0          6m35s

my-deployment-apache-859486bd8c-6mcq4   1/1     Running       0          6m50s

my-deployment-apache-859486bd8c-cdb6z   0/1     Terminating   0          6m50s

my-deployment-apache-859486bd8c-kpwb8   0/1     Terminating   0          6m50s

my-deployment-apache-859486bd8c-rmw8d   0/1     Terminating   0          6m35s

my-deployment-apache-859486bd8c-v59b8   0/1     Terminating   0          44m

my-deployment-apache-859486bd8c-xmv28   0/1     Terminating   0          6m35s



[root@kub-master-1 ~]# kubectl get pod -n my-site

NAME                                    READY   STATUS    RESTARTS   AGE

my-deployment-apache-859486bd8c-6mcq4   1/1     Running   0          7m48s




Источник: https://sidmid.ru/kubernetes-автоскейлинг-приложений-при-помощ/



2023-04-02T22:26:47

Blender 3.5 выходит с большими улучшениями в системе волос и многим другим.

Blender 3.5

Всплеск Blender 3.5 от Николь Морена

Blender Foundation объявила о выпуске новой версии своего бесплатного пакета 3D-моделирования Blender 3.5, который подходит для решения множества задач, связанных с 3D-моделированием.

Также стоит упомянуть, что одновременно с этим в ветке Long Term Support (LTS) сделан патч-релиз Blender 3.3.5, который будет получать обновления до сентября 2024 года.



Читать →