Anton Kuzmichev

debian или ubuntu (точнее те что на основе пакетного менеджера .deb) имеют штатный инструмент - debootstrap, он позволяет собрать минимальную сборку порядка 200мб, в которую вы можете доустановить необходимые пакеты. Причем ничто не мешает все манипуляции проводить с ноутбука (т.е. отличная архитектура).

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

Я не знаю никакой другой системы пакетов (т.е. инструмент, позволяющий обслуживать программные пакеты и их зависимости), которая позволила бы создать сборку на столько эффективной и компактной по использованию ресурсов. Я собирал инсталляцию для eeepc с xserver и awesome de, с затратами оперативной памяти в 50мб (после запуска сразу доступен запуск браузера или просмотр видео mvp), когда как минимальная сборка на базе ubuntu занимала 200 или 300мб (и оставшихся не хватало для комфортной работы браузера).

man signal

#include <signal.h>
void sigprocess (int sign){
 /* process signal here */
}

...
int main(){
...
 signal (SIGUSR1, sigprocess);
...
}

P.S. если обработчик не нужен, можно
signal(SIGUSR1, SIG_IGN);

Поставить pg_stat_statements, спустя какое-то время посмотреть что тот собрал. Например, нашим отчётом

Сам решил

import datetime as datetime_class # забыл добавить в ответ

duration = datetime.strptime(duration, "%H:%M:%S")
x_duration =datetime_class.timedelta(hours=duration.hour, minutes=duration.minute, seconds=duration.second).total_seconds()	
duration = timedelta(seconds = x_duration)

Приветствую.

Ниже пример конфигурации daemon set для bare-metal k8s. Если будут вопросы - пишите.

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: nginx-ingress-lb
  labels:
    name: nginx-ingress-lb
  namespace: kube-system
spec:
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        name: nginx-ingress-lb
      annotations:
        prometheus.io/port: '10254'
        prometheus.io/scrape: 'true'
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      # This may be used to push kubernetes SVCs to the internet
      # Label a secure host as 'edge-router' + setup forwarding, SSL certs, etc.
      hostNetwork: true
      nodeSelector:
        node-role.kubernetes.io/ingress: "true"
      terminationGracePeriodSeconds: 60
      containers:
      - image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.0
        name: nginx-ingress-lb
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          timeoutSeconds: 1
        ports:
        - containerPort: 80
          hostPort: 80
        - containerPort: 443
          hostPort: 443
        env:
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
        args:
        - /nginx-ingress-controller
        - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
        - --configmap=$(POD_NAMESPACE)/nginx-ingress-configmap
        - --default-ssl-certificate=$(POD_NAMESPACE)/default-ssl-cert

Под Centos не пробросился под 18 убунтой всё заработало.
Спасибо за внимание!

docker run -it -p 8080:8080 -d --rm --privileged -v /dev/bus/usb:/dev/bus/usb ubuntu

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

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

• Комманда docker - это консольный интерфейс (CLI) для работы с Docker
  
• docker build создает по заданному Dockerfile образ контейнера
  
• docker tag присваивает указанному образу указанный тег (опция -t для build делает то же самое)
  
• docker pull скачивает указанный образ из удаленного регистра на текущую машину
  
• docker push заливает указанный образ в удаленный регистр
  
• docker run запускает новый контейнер из указанного образа
  
• docker ps выводит список текущих "бегущих" контейнеров
  

Команда docker не жонглирует файлами, она жонглирует образами и контейнерами, а они от нас абстрагированы Docker'ом, как что-то эфемерное. То есть выполняя комманду docker pull Вы не скачиваете образ в ту папку, где выполняете команду, и уж точно не скачиваете какие-либо файлы. Все что Вы делаете этой командой - это скачиваете образ в локальное хранилище Docker'а, дабы Docker daemon мог запустить контейнер на основании этого образа.

Команда docker-compose - это уже совсем другая команда. Все что она делает - это читает указанный YAML-манифест и выполняет соответствующие команды Docker. Это всего лишь позволяет декларативно указывать желаемые сценарии при работе с Docker в удобном формате. Но ни команда docker, ни docker-compose, не предоставляют ничего для того, чтобы транспортировать/обновлять версии Ваших манифестов где-то там. Docker, опять таки, жонглирует образами и контейнерами, не более.

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

Касательно совета docker-compose.yml под каждый env, все правильно советовали. Именно так это и задумывалось. Вы в манифесте указываете отнюдь не разные окружения (development, production), а набор контейнеров, которые должны бежать в одной связке одной логической единицей (концепция POD'ов). Ничего не запрещает делать и так, как сделали Вы, но это сродни использованию дуршлага в роли миски для еды: сегодня Вы нормально из него наворачиваете пельмени, а завтра супчик в нем уже куда-то не туда утекает.

Воркфлоу в Вашем случае можно организовать следующим образом:

1. На dev-машине у Вас один docker-compose.yml, согласно которому контейнер перед запуском собирается из сорцов.
   
2. Когда у Вас готова новая версия приложения, Вы его собираете через docker build, присваиваете ему номер версии через docker tag и отправляете в удаленный регистр образов через docker push.
   
3. На prod-машине у Вас отдельный docker-compose.ymlв котором указано запускать конкретную версию образа (и никаких build). Новая версия приложения - меняем тег образа в манифесте и перезапускаем контейнеры. При выполнении docker-compose образ автоматически скачается перед запуском, если его нет локально. Если же Вы обновили образ конкретной версии, которая уже была скачана ранее, то да, нужно выполнить docker pull перед стартом, дабы скачать новый образ.
   

Дополнительный совет:
Сборку образа и его заливку в удаленный регистр часто удобно автоматизировать с помощь Makefile'ов.

Нашел инфу, пароль по дефолту android.