Първият ми Docker image (с малко помощ от AI): WebSSH в контейнер

От известно време си играя с Docker. Първо започнах както повечето хора – с готови контейнери, docker-compose файлове от GitHub и леко променяне на конфигурации. В един момент обаче реших, че е време да направя нещо собствено.

Така се появи първият ми публичен Docker image:

https://hub.docker.com/r/danaildr/webssh

Не е революционен проект. Не е и някакъв сложен софтуер. Но е нещо, което съм направил сам… или по-точно сам + AI.


Каква е идеята

Image-ът представлява web базиран SSH клиент, който можеш да достъпиш през браузър.

Тоест:

  • отваряш браузър
  • виждаш терминал
  • връзваш се към SSH сървър

Без локален SSH клиент, без допълнителен софтуер.

Подобни неща има доста. Причината да си направя собствен не беше, че светът има нужда от още един WebSSH клиент, а че исках да разбера как работи и как се прави Docker image от нулата.


Защо изобщо реших да го направя

Честно казано, първоначалната идея беше доста практична.

Имам няколко сървъра и устройства в хомелаба и понякога е удобно да имам SSH достъп директно през браузър. Особено когато съм на чужд компютър или на машина, на която не искам да инсталирам нищо.

Но има и още една много важна причина.

Ако контейнерът работи на машина, която има отворен към интернет порт 8080 (портът на Web интерфейса), той на практика може да се използва като SSH gateway към вътрешната мрежа.

Това означава следното:

  • не е необходимо да се отваря порт 22 към интернет
  • SSH достъпът до вътрешните машини остава само вътре в локалната мрежа
  • отвън се вижда само Web интерфейсът

На практика получаваш нещо като малък web базиран bastion host.

С други думи:

Така SSH портовете на вътрешните машини не се експонират към интернет, което добавя една допълнителна доза сигурност.

Разбира се, това не е пълноценна security архитектура и не заменя неща като VPN, но за хомелаб или малка инфраструктура е доста удобен компромис между достъп и сигурност.


Ролята на AI (или как да не се правим на герои)

Няма да се правя на велик програмист.

Истината е, че голяма част от кода е написана с помощта на AI. Аз по-скоро играех ролята на:

  • човекът, който задава въпросите
  • човекът, който чупи нещата
  • човекът, който казва „това не работи“

и после заедно с AI ги оправяхме.

Това не означава, че всичко става магически. Всъщност доста време отиде в:

  • дебъгване
  • промени по Dockerfile
  • тестване
  • разбиране защо нещо не работи

AI е мощен инструмент, но ако не разбираш поне малко какво се случва, бързо се озоваваш в хаос.


Какво има вътре в image-а

Контейнерът предоставя прост web интерфейс за SSH достъп.

Технически погледнато:

  • Python backend
  • SSH връзка чрез библиотеката Paramiko
  • терминал в браузъра
  • минимален Docker image

Опитах се Dockerfile-ът да е сравнително чист:

  • базиран на python:3.11-slim
  • използва non-root user
  • оптимизиран build процес
  • минимални зависимости

Целта беше лек и сравнително сигурен контейнер, който може да се използва в реална среда.


Как да го стартираш

Най-простият начин е:

След това отваряш:

и получаваш терминал директно в браузъра.

Инсталиране с Docker Compose

Ако предпочиташ да управляваш контейнерите си чрез Docker Compose (което честно казано е по-удобният вариант, особено ако вече имаш повече услуги на машината), можеш да стартираш контейнера и по този начин.

Създай файл docker-compose.yml със следното съдържание:

След това стартирай контейнера с:

И след няколко секунди Web интерфейсът ще бъде достъпен на:

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

  • контейнерът може лесно да се стартира отново
  • конфигурацията е лесна за промяна
  • може да се добавят допълнителни услуги по-късно

А ако вече използваш Docker Compose за други неща (reverse proxy, база данни, monitoring и т.н.), този контейнер спокойно може да стане част от същия stack.


Какво научих от този проект

Няколко неща станаха доста ясни:

1. Docker изглежда прост, но има доста детайли
Dockerfile, layers, permissions, networking – всичко това има значение.

2. Debug-ването на контейнер понякога е… интересно
Особено когато нещо работи на локалната машина, но не и в контейнера.

3. AI е страхотен помощник, но не е заместител на мисленето
Понякога предлага решения, които изглеждат логични, но просто не работят.

4. Най-добре се учи чрез малки реални проекти


Какво следва

Този image е по-скоро първа версия / експеримент.

В бъдеще може да добавя:

  • authentication слой
  • reverse proxy интеграция
  • HTTPS
  • multi-user support
  • по-добър интерфейс

А може и просто да го оставя като първия си Docker проект и да продължа към следващия.


И така, за финала

Не съм топ програмист.
Не съм DevOps инженер.
Просто човек, който обича да си човърка по сървъри и да си прави малки инструменти.

С малко търпение, експерименти и помощ от AI можеш да стигнеш доста по-далеч, отколкото си мислиш.

A20-OLinuXino-LIME2 като HOME SERVER

В началото на месец декември закупих комплекта Home-server, който Олимекс предлагат.

Комплекта включва платката(SBC) A20-OLinuXino-LIME2-s16M, 32GB micro SD flash card, метална кутия за платката, метална кутия за 2,5″ харддист (или SATA SSD), платка за свързване на SATA HDD/SSD към SBC, захранващ адаптер и батерия 1400mAh 3,7V и UTP кабел за връзка с интернет.

Може да закупите комплекта от тук.

За операционна система избрах Armbian 21 Buster minimal с Linux kernel 5.10.х. Както се подразбира от името, това е операционна система базирана на Debian Buster и е без графична среда, подходяща за домашен сървър.

A20-OLinuXino-LIME2-s16M има двуядрен Cortex-A7 процесор с честота 1000 MHz, 1GB DDR3 RAM, SATA конектор, 2 USB конектора, гигабитов мрежов адаптер,HDMI конектор, конектор за батерия и много GPIO.

Причината да избера точно този комплект е в това, че Олимекс произвеждат тази платка като OSHW (опен сорс хардуер). Платката е достатъчно мощна за домашен сървър и разполага с гигабитов порт за връзка с интернет. SATA интерфейса позволява да се включи допълнителен диск, който да съхранява файловете. Допълнителен плюс е вградената поддръжка на батерия, което позволява работата на платката дори и след прекъсване на електрозахранването. Всички тези плюсове направиха A20-OLinuXino-LIME2-s16M, предпочитана за мен платка пред конкурентите от RPi.

Първоначално монтирах един 2TB Seagate. Операционната система беше инсталирана на SD картата. Машината работи до 6-ти март (повече от 2 месеца) без прекъсване.

Написах скрипт който да извършва мониторинг на системата и на всяка минута записва в база данни основни параметри – ток и напрежение на батерията и AC адаптера, температура на процесора, използвано място на дисковете. Както и проверка дали са достъпни няколко уеб сайта, за мониторинг на свързаността . Също така инсталирах и cli версията на speedtest и на всеки 15 мин извършвах спийдтест и записвах резултата в базата данни.

Всичко това доведе до повреда на файловата система на SD картата. Явно множеството записи във файловата система, не са препоръчителни за SD картите. Скриптовете генерират около 200 000 записа в базата данни ( за 2 месеца работа), и всичко това без да броим промените по файловете които се извършват при инсталирането и ъпдейтването на пакетите.

След тази повреда, направих малка промяна. Закупих един 240GB SSD PNY CS900 SSD. Този път реших да инсталирам операционната система на него. Това е лесно, защото Armbian разполага с конфигурационен скрипт, който копира системата на SSD и коригира boot процеса. Така конфигурацията на системата позволява работата на операционната система на SSD диска. Това позволява да се извършват записи в базата данни на всяка минута, без това да повреди файловата система.

Към момента машината изпълнява функциите на самба сървър, уеб сървър, медиен сървър и мониторинг система. Инсталиран е следния софтуер за да се изпълни това – samba, apache2, php7.3, mariadb 10.3, minidlna, grafana и observium.

Благодарение на PHP и Apache, спретнах тази демонстрационна страничка home.danaildr.eu. Кода не е много елегантен, даже може да се каже, че си е спагети код. Поради тази причина за момента няма да го публикувам. На по-късен етап ще публикувам него и скриптовете събиращи данните за системата.

Системата консумира около 2W електроенергия в покой, а когато се натовари около 2,7-2,9W. При тестовете за работа на батерия, при 1 час работа заряда на батерията пада до около 60%, което предполага около 2 часа и половина работа. В сайта на Олимекс е записано, че батерията осигурява около 3 часа автономна работа. На снимките по-долу се виждат няколко графики от observium и grafana които показват състоянието на системата и историята на някои от следените параметри.

HBO GO под Linux

HBO – Home Box Office или както се рекламират сами „Това не е телевизия, това е HBO“.

Множество доставчици на кабелна телевизия в България, предоставят каналите на HBO на своите клиенти. Част от тях предлагат и допълнителната онлайн услуга на HBO, а именно HBO GO.

Дали вашият оператор предлага услугата HBO GO може да проверите от тук.

Според HBO, услугата HBO GO  е достъпна за компютри с Windows и Mac OS, телефони и таблети с Android, телефони с iOS и телевизорите на Samsung и LG (също и някои телевизори с Android и някои модели на Sony).

За Линукс компютри не се споменава, а ако зададете въпрос на съпорт-а им, ще ви отговорят, че официално не се поддържа. Това наистина е така, но не значи, че не може да се ползва услугата. Фактически всеки линукс компютър с инаталиран  firefox браузър, може да се възползва от тази услуга.

За да гледате HBO GO с браузъра Firefox, е необходимо да отворите нов раздел и в адрес бара да изпишете about:config , следващата стъпка е лесна, в търсачката изписвате widevine. В показаните резултати намерете media.gmp-widevinecdm.enabled и променете стойността му на true (става с двойно почукване върху false). Ако стойността му е true, значи може да влезете със своя HBOGO акаунт и да се гледате любимите си филми или предавания.

HBO GO под Linux

 

Continue reading „HBO GO под Linux“