Посты с тэгом devops


[Перевод] Как написать смарт-контракт на Python в сети Ontology. Часть 3: Runtime API



Это 3-я часть из серии обучающих статей о создании смарт-контрактов на Python в блокчейн сети Ontology. В предыдущих статьях мы познакомились с
1. Blockchain & Block API
2. Storage API.

Теперь, когда Вы имеете представление о том, как вызвать подходящее API для постоянного хранилища при разработке смарт-контракта с помощью Python в сети Ontology, давайте перейдём к знакомству с тем, как использовать Runtime API (Contract Execution API). Runtime API имеет 8 связанных API, которые предоставляют общие интерфейсы для выполнения контракта и помогают разработчикам получать, преобразовывать и проверять данные.
Читать дальше →


DeepPavlov для разработчиков: #2 настройка и деплоймент

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

Договоримся, что все скрипты запуска библиотеки выполняются в environment Python с установленной библиотекой DeepPavlov (про установку см. первую статью, про virtualenv можно прочитать здесь). Примеры из этой статьи не требуют знания синтаксиса Python.




[Перевод] Как написать смарт-контракт на Python в сети Ontology. Часть 2: Storage API


Это вторая часть из серии обучающих статей о создании смарт-контрактов на Python в блокчейн сети Ontology. В предыдущей статье мы познакомились с Blockchain & Block API смарт-контракта Ontology.

Сегодня мы обсудим, как использовать второй модуль— Storage API. Storage API имеет пять связанных API, которые позволяют добавление, удаление и изменения в постоянном хранилище в смарт-контрактах на блокчейне.
Читать дальше →


[Перевод] Как написать смарт-контракт на Python в сети Ontology. Часть 1: Blockchain & Block API


Это первая часть из серии обучающих статей о создании смарт-контрактов на Python в блокчейн сети Ontology при помощи инструмента разработки смарт-контрактов SmartX.

В этой статье мы начнём знакомство с API смарт-контракта Ontology. API смарт-контракта Ontology разделен на 7 модулей:
  1. Blockchain & Block API,
  2. Runtime API,
  3. Storage API,
  4. Native API,
  5. Upgrade API,
  6. Execution Engine API и
  7. Static & Dynamic Call API.


Blockchain & Block API является основной частью системы смарт-контрактов Ontology. Blockchain API поддерживает базовые операции блокчейн-запроса, как например получение текущей высоты блока, тогда как Block API поддерживает базовые операции блок-запроса, как например запрашивание количества транзакций для данного блок


Kubernetes Operator на Python без фреймворков и SDK



Go на данный момент является монополистом среди языков программирования, которые люди выбирают для написания операторов для Kubernetes. Тому есть такие объективные причины, как:

  1. Существует мощнейший фреймворк для разработки операторов на Go — Operator SDK.
  2. На Go написаны такие «перевернувшие игру» приложения, как Docker и Kubernetes. Писать свой оператор на Go — говорить с экосистемой на одном языке.
  3. Высокая производительность приложений на Go и простые инструменты для работы с concurrency «из коробки».

NB: Кстати, как написать свой оператор на Go, мы уже описывали в одном из наших переводов зарубежных авторов.

Но что, если изучать Go вам мешает отсутствие времени или, банально, мотивации? В


Внедрение Airflow для управления Spark-джобами в ivi: надежды и костыли

Задача деплоя моделей машинного обучения в продакшн — это всегда боль и страдания, потому что очень некомфортно вылезать из уютного jupyter notebook в мир мониторинга и отказоустойчивости.

Мы уже писали про первую итерацию рефакторинга рекомендательной системы онлайн-кинотеатра ivi. За прошедший год мы почти не дорабатывали архитектуру приложения (из глобального — только перезд с устаревших python 2.7 и python 3.4 на «свежий» python 3.6), зато добавили несколько новых ML моделей и сразу столкнулись с проблемой выкатывания новых алгоритмов в продакшн. В статье я расскажу про наш опыт внедрения такого инструмента управления потоками выполнения задач как Apache Airflow: почему у команды возникла эта необходимость, чем не устраивало существующее решение, какие костыли пришлось запилить по дороге и что из этого получилось.

→ Видео-версию доклада можно посмотреть на ютубе (начиная с 03:00:00)



[Из песочницы] Создание Dataflow шаблона для стриминга данных из Pub/Sub в BigQuery на базе GCP с помощью Apache Beam SDK и Python


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


Весь процесс включает в себя участие следующих сервисов Google Cloud Platform:


  • Pub/Sub — сервис для realtime стриминга данных
  • Dataflow — сервис для преобразования данных (может
    работать как в realtime так и в batch режиме)
  • BigQuery — сервис для хранения данных в виде таблиц
    (поддерживает SQL)
Читать дальше →


Опыт построения инфраструктуры на микросервисной архитектуре


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


У нас в небольшом банке были большие проблемы: 3 python монолита связанных чудовищным количеством синхронных RPC взаимодействий с большим объемом legacy. Что бы хотя бы отчасти решить все возникающие при этом проблемы было принято решение перейти на микросервисную архитектуру. Но прежде чем решиться на такой шаг нужно ответить на 3 основных вопроса:


  • Как разбить монолит на микросервисы и какими критериями следует при этом руководствоваться.
  • Каким образом микросервисы будут взаимодействовать?
  • Как осуществлять мониторинг?

Собственно кратким



Разворачиваем Kubernetes на десктопе за несколько минут с MicroK8s

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

Сегодня я хочу рассказать о пакете MicroK8s, который без преувеличения позволяет развернуть Kubernetes локально за несколько минут, и начать разработку. Не требуется даже предустановленных Docker и Kubernetes, т.к. все включено. В предлагаемом Вам уроке будет рассмотрен деплой приложения Django в локальной среде Kubernetes.

В качестве источника я шел вслед за серией статей



Разворачиваем Kubernetes на десктопе за несколько минут с MicroK8s

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

Сегодня я хочу рассказать о пакете MicroK8s, который без преувеличения позволяет развернуть Kubernetes локально за несколько минут, и начать разработку. Не требуется даже предустановленных Docker и Kubernetes, т.к. все включено. В предлагаемом Вам уроке будет рассмотрен деплой приложения Django в локальной среде Kubernetes.
Читать дальше →