Nezinu, ar ko salīdzināt provisioning. Varbūt ar kaķi? Izskatās, ka var arī bez tā, bet ar to ir nedaudz labāk. Īpaši, ja tas strādā))
Problēmas izvirzīšana:
- Vēlos ātri, viegli un droši konfigurēt SIP tālruņus. Izmantojot tālruņa uzstādīšanu un jo īpaši tā pārkonfigurēšanu.
- Daudzi ražotājiem ir savi konfigurācijas formāti, savas utilītas konfigurāciju ģenerēšanai, savi konfigurācijas aizsardzības veidi. Un risināt katru no tiem negribas.
- Daudzas provisioning risinājumi a) ir orientēti uz vienu ražotāju vai vienu tālruņu sistēmu, b) ir gana izsmalcināti, pilns ar skriptiem, parametriem, brūsss…
Par 3. punktu piezīmēšu, ka ir lieliskas provisioning sistēmas , , , kur ir publiski pieejami paraugi dažādu ražotāju tālruņiem. Ir arī komerciāli risinājumi, kur var iestatīt moduļa provisioning iestatījumus dažādu ražotāju tālruņiem, piemēram, Yeastar PBX.
Habrā arī ir pilns ar receptēm, kā konfigurēt dažādu ražotāju ierīces: , . Bet kā zināms, katrai sistēmai ir fatāla trūkuma. Tāpēc izveidosim savu velosipēdu.
savu formātu
Kā saka xkcd, ja nevēlies izprast 14 formātus — . Tāpēc mēs izmantojam kopīgas iestatījumus jebkuram tālrunim un izveidosim savu json konfigurācijas formātu.
Aptuveni šādu:
{
"key": "sdgjdeu9443908",
"token": "590sfdsf8u984",
"model": "gxp1620",
"vendor": "grandstream",
"mac": "001565113af8",
"timezone_offset": "GMT+03",
"ntp_server": "pool.ntp.org",
"status": true,
"accounts": [
{
"name": "Mobilon",
"line": 1,
"sip_register": "sip.mobilonsip.ru",
"sip_name": "sip102",
"sip_user": "sip102",
"sip_password": "4321",
"sip_auth": "sip102"
}
]
}Tādējādi, jebkurā tālrunī ir nepieciešams iestatīt lokālo laiku, SIP līnijas. Šeit viss ir vienkārši. Vairāk piemēru varat skatīt .
savam provisioning serverim
Ražotāja rokasgrāmatā parasti ir punkts, kur ir teikts: paņemiet CSV, ierakstiet tur lietotājvārdu-paroli-MAC adresi, ar mūsu firmas skriptu ģenerējiet failus, novietojiet tos uz Apache webservera, un viss būs labi.
Nākamajā rokasgrāmatas punktā parasti stāsta, ka vēl var arī šifrēt ģenerēto konfigurācijas failu.
Bet tas viss ir klasika. Mūsdienu pieeja ar smoothie un Twitter saka, ka ir jāizveido gatavs webserveris, kas nebūs tik jaudīgs kā Apache, bet darīs tikai vienu mazu uzdevumu. Formēt un nodot konfigurācijas pēc saites.
Šeit apstāsimies un atgādināsim, ka gandrīz visi SIP telefoni šobrīd var iegūt konfigurācijas caur http/https, tāpēc citas realizācijas (ftp, tftp, ftps) netiks apskatītas. Pēc tam katrs tālrunis zina savu mac adresi. Tāpēc izveidosim divas saites: viena personīga — pēc ierīces atslēgas, otra vispārēja, kas darbojas pēc kombinācijas vispārējais tokens un mac adrese.
Arī es neapstāšos pie zero-config, t.i., tālruņa iestatīšanas 'no nulles', t.i., jūs to iedurat tīklā, un tas tūlīt sāk darboties. Nē, manā scenārijā jūs to iedurat tīklā, veicat iepriekšēju iestatīšanu (iestatāt to, lai iegūtu konfigurāciju no apkalpojošā servera), un tad baudāt piña coladas un pārkonfigurējat tālruni, kā vajag, caur provizijas sistēmu. Nodrošināt Option 66 — tas ir DHCP servera pienākums.
Starp citu, es pilnīgi esmu noguris teikt 'provisioning', tāpēc vārds ir saīsināts līdz 'provizija', lūdzu, nesitiet mani ar kājām.
Un vēl: mūsu provizijas serverim nav UI, t.i., lietotāja interfeisa. Iespējams, pagaidām, bet neesmu pārliecināts, jo tas man nav nepieciešams. Toties ir API, lai saglabātu/dzēstu iestatījumus, iegūtu atbalstīto ražotāju, modeļu sarakstu, viss aprakstīts atbilstoši swagger specifikācijai.
Kāpēc API, bet ne UI? Tāpēc, ka man jau ir sava telefonsistēma, un man ir avots akreditācijas datiem, no kura man pietiek ņemt šos datus, sakomponēt nepieciešamo json un publiskot to provizijas serverī. Un jau provizijas serveris saskaņā ar noteikumiem, kas norādīti json failā, izsniegs nepieciešamajai ierīcei tās konfigurāciju vai neizsniegs, ja ierīce nav tāda vai neatbilst kritērijiem, kas norādīti arī šajā json.
Šāds iznāca provizijas mikroserviss. Tas saucas , avota kods ir pieejams gitā, ir arī , docker izmantošanas piemērs .
Galvenās iezīmes:
jebkurā gadījumā ierobežota piekļuve konfigurācijai laikā, pēc noklusējuma 10 minūtes. Ja vēlaties vēlreiz padarīt konfigurāciju pieejamu — atkārtoti publiskojiet konfigurāciju.
viens formāts visiem ražotājiem, visa pielāgošana ir iekļauta sonata, nosūtat standartizētu json, iestatāt jebkuru pieejamo aparatūru.
visas izsniegtās konfigurācijas ierīcēm tiek reģistrētas, visas problemātiskās vietas var apskatīt žurnālā un redzēt kļūdas.
Iespējams izmantot vienu kopīgu saiti ar token, katrs telefons saņem savu konfigurāciju, norādot MAC adresi. Vai arī personīgu saiti pēc key.
API, lai pārvaldītu (management) un izsniegtu konfigurācijas telefoniem (provisioning), ir sadalīti pa portiem.
Testi. Man bija ļoti svarīgi fiksēt izsniegtā konfidēšanas formātu un visus parastos konfidēšanas situāciju testus. Lai tas viss strādātu skaidri.
Mīnusi:
Šobrīd šifrēšana sonata ietvaros netiek izmantota. Proti, protams, jūs varat sākt izmantot https, uzstādot, piemēram, nginx pirms sonata. Bet firmas metodes pagaidām vēl nav iesaistītas. Kāpēc? Projekts vēl ir jauns, ir izsniegti labi vien simts ierīču. Un, protams, es vācu idejas, atsauksmes. Turklāt, lai visu padarītu drošu, lai konfidēšanas nevarētu noklausīties tīklā, iespējams, ir vērts ieguldīt šifrēšanas atslēpēs, tls un tam līdzīgās lietās, bet tas būs turpinājums.
UI trūkums. Iespējams, tas ir ievērojams trūkums gala lietotājam, taču sistēmas administratoram drīzāk svarīga ir konsoles utilīta, nevis pilnvērtīga lietotne. Sadarbības konsoles utilītu bija plānots izstrādāt, bet neesmu pārliecināts, vai tā ir nepieciešama?
Ko mēs iegūstam?
Neliels un vienkāršs tīmekļa serveris vairāku telefona modeļu piegādei ar API pārvaldībai.
Vēlreiz, kā tam vajadzētu darboties?
- Uzstādam sonata.
- Veidojam json konfigurāciju un publicējam to sonata.
- Tad saņemam no sonata saiti piegādei.
- Tad šo saiti norādām telefonā.
- Ierīce lejupielādē konfigurāciju.
Nākamajā izmantošanā tikai divi soļi:
- Veidojam json konfigurāciju un publicējam to sonata.
- Ierīce lejupielādē konfigurāciju.
Kādi telefoni tiek pabeigti?
Ražotāji: Grandstream, Fanvil, Yealink. Konfigurācijas ražotāja ietvaros ir apmēram vienādas, bet var atšķirties atkarībā no programmatūras – iespējams, būs nepieciešams veikt papildu testus.
Kādi noteikumi var tikt noteikti?
Pēc laika. Jūs varat noteikt laiku, līdz kuram konfigurācija būs pieejama.
Pēc MAC adreses. Izsniegšanas laikā ar personīgu saiti ierīces MAC adrese arī tiks pārbaudīta.
Pēc IP. Pēc IP adreses, no kuras tika veikts pieprasījums.
Kā mijiedarboties ar sonata?
Caura API, veicot http pieprasījumus. API būs pieejama jūsu instalācijā. Tā kā API atbalsta swagger specifikāciju, varat izmantot testējošiem pieprasījumiem uz API.
Labi, lieliski. Forša lieta, kā pamēģināt?
Visvieglāk ir izvērst docker-attēlu, balstoties uz repozitoriju . Repozitorijā ir instalēšanas instrukcija.
А если знаю node.js?
Ja jums ir pieredze ar JavaScript, jūs ātri sapratīsiet, kā šeit viss darbojas.
Vai sonata attīstīsies?
Daļēji esmu sasniedzis savus mērķus. Turpmākā attīstība ir saistīta ar manām uzdevumu lietām, kas saistītas ar automātisko telefona iestatījumu veikšanu. Ir iespēja paplašināt konfigurācijas telefona pogu iestatīšanai, pievienot provizionēšanas adreses grāmatas, iespējams, vēl kaut ko, lūdzu, rakstiet komentāros.
Kopsavilkums un pateicības
Būšu priecīgs par konstruktīviem priekšlikumiem/iebildumiem/komentāriem un jautājumiem, jo var būt, ka kaut kas nav skaidri aprakstīts.
Arī izsaku pateicību visiem kolēģiem, kas palīdzēja, konsultēja, testēja, nodrošināja/uzdāvināja telefonus testēšanai. Patiesībā projektam ir dažādā mērā pievienojušies daudzi cilvēki, ar kuriem esmu sazinājies darba, čatu un e-pasta ietvaros. Paldies par idejām un domām. ‘ē, čatos un e-pastos. Paldies par idejām un domām.
Avots: habr.com
