Jeg vet ikke hva jeg skal sammenligne levering med. Kanskje med en katt? Det virker mulig uten det, men med det er det litt bedre. Spesielt hvis det fungerer))
Formulering av problemet:
- Jeg vil sette opp SIP-telefoner raskt, enkelt og trygt. Når du installerer en telefon, og enda mer når du rekonfigurerer den.
- Mange leverandører har sine egne konfigurasjonsformater, sine egne verktøy for å generere konfigurasjoner og sine egne måter å beskytte konfigurasjoner på. Og jeg vil egentlig ikke ha med alle å gjøre.
- Mange klargjøringsløsninger, a) er fokusert på én leverandør eller ett telefonsystem, b) er ganske tungvint å implementere, mange skript, parametere, brrr...
Når det gjelder punkt 3, vil jeg kommentere at det finnes utmerkede provisjonssystemer , , , hvor maler for telefoner fra ulike leverandører er offentlig tilgjengelig. Det finnes kommersielle løsninger hvor du også kan konfigurere driften av telefoner fra forskjellige produsenter i klargjøringsmodulen, for eksempel Yeastar PBX.
Habré er også full av oppskrifter på hvordan du setter opp enheter fra forskjellige leverandører: , . Men som de sier, alle systemer har en fatal feil. Så vi lager vår egen sykkel.
ditt eget format
Som de sier i xkcd, hvis du ikke vil håndtere 14 formater - . Derfor bruker vi vanlige innstillinger for enhver telefon og lager vårt eget json-konfigurasjonsformat.
Noe sånt som dette:
{
"key": "sdgjdeu9443908",
"token": "590sfdsf8u984",
"model": "gxp1620",
"vendor": "grandstream",
"mac": "001565113af8",
"timezone_offset": "GMT+03",
"ntp_server": "pool.ntp.org",
"status": true,
"accounts": [
{
"name": "Мобилон",
"line": 1,
"sip_register": "sip.mobilonsip.ru",
"sip_name": "sip102",
"sip_user": "sip102",
"sip_password": "4321",
"sip_auth": "sip102"
}
]
}Så i enhver telefon må du konfigurere lokal tid og SIP-linjer. Alt er enkelt her. Du kan se flere eksempler .
din egen serverklargjøring
I produsentens manualer er det vanligvis et punkt der det står: ta en csv, skriv ned påloggingspassordet-mac-adressen din, generer filer ved hjelp av vårt proprietære skript, legg dem under Apache-nettserveren og alt blir bra.
Det neste avsnittet i håndboken forteller deg vanligvis at du også kan kryptere den genererte konfigurasjonsfilen.
Men disse er alle klassikere. Den moderne tilnærmingen med smoothies og Twitter sier at du må lage en ferdig nettserver som ikke vil være like kraftig som Apache, men som bare vil gjøre en liten ting. Generer og send konfigurasjoner ved hjelp av en lenke.
La oss stoppe her og husk at nesten alle SIP-telefoner nå kan motta konfigurasjoner via http/https, så vi vurderer ikke andre implementeringer (ftp, tftp, ftps). Deretter kjenner hver telefon sin egen MAC-adresse. Derfor vil vi lage to lenker: en personlig - basert på enhetsnøkkelen, den andre generelle, som fungerer ved å bruke en kombinasjon av et felles token og en MAC-adresse.
Jeg vil heller ikke dvele ved zero-config, dvs. sette opp telefonen fra bunnen av, dvs. du koblet den til nettverket og den begynte å fungere. Nei, i mitt scenario kobler du den til nettverket, gjør det foreløpige oppsettet (sett det opp til å motta konfigurasjonen fra klargjøringsserveren), og drikker deretter pina colada og rekonfigurerer telefonen etter behov gjennom klargjøringen. Distribusjon av alternativ 66 er DHCP-serverens ansvar.
Forresten, jeg var helt lei av å si "provisjonering", så ordet ble forkortet til "provisjon", vennligst ikke spark meg.
Og en ting til: klargjøringsserveren vår har ikke et brukergrensesnitt, dvs. brukergrensesnitt. Kanskje foreløpig, men ikke sikker, fordi... Jeg trenger det ikke. Men det er et API for å lagre/slette innstillinger, få en liste over støttede leverandører, modeller, alt er beskrevet i henhold til kanonene til swagger-spesifikasjonen.
Hvorfor API og ikke UI? Fordi Jeg har allerede mitt eget telefonsystem, så har jeg en kilde til legitimasjon, der jeg bare trenger å ta disse dataene, kompilere den nødvendige json og publisere den på klargjøringsserveren. Og klargjøringsserveren, i henhold til reglene spesifisert i json-filen, vil gi den nødvendige enheten sin konfigurasjon eller vil ikke gi den hvis enheten ikke er riktig eller ikke oppfyller kriteriene som også er spesifisert i denne json.
Slik ble klargjøringsmikrotjenesten. Kalt , kildekoden er tilgjengelig på GitHub, det er også , eksempel på docker-bruk .
Nøkkelegenskaper:
-
i alle fall begrenset tilgang til konfigurasjonen av tid, som standard 10 minutter. Hvis du vil gjøre konfigurasjonen tilgjengelig igjen, publiser konfigurasjonen på nytt.
-
ett format for alle leverandører, alle justeringer fjernes i sonata, du sender standardisert json, konfigurerer alt tilgjengelig utstyr.
-
alle konfigurasjoner utstedt til enheter logges, alle problemområder kan sees i loggen og feil kan sees
-
Det er mulig å bruke én felles lenke med et token; hver telefon mottar sin egen konfigurasjon ved å spesifisere mac-adressen. Eller en personlig lenke via nøkkel.
-
APIer for administrasjon (administrasjon) og klargjøring av konfigurasjoner til telefoner (klargjøring) er delt etter porter
-
Tester. Det var veldig viktig for meg å fikse formatet til den utstedte konfigurasjonen og dekke alle de vanlige situasjonene med å utstede en konfigurasjon med tester. Slik at alt fungerer klart.
Cons:
Foreløpig er kryptering ikke brukt på noen måte i Sonata. De. du kan selvfølgelig begynne å bruke https ved å sette nginx foran sonata for eksempel. Men proprietære metoder har ennå ikke blitt brukt. Hvorfor? Prosjektet er fortsatt ungt, det har lansert sine første hundre enheter. Og selvfølgelig samler jeg inn ideer og tilbakemeldinger. Videre, for å gjøre alt sikkert, slik at konfigurasjonene ikke kan sniffes på nettverket, er det sannsynligvis verdt å bry seg med krypteringsnøkler, tls og pinnsvinet med dem, men dette blir en fortsettelse.
Mangel på UI. Kanskje dette er en betydelig ulempe for sluttbrukeren, men for en systemadministrator er et konsollverktøy viktigere enn en fullverdig applikasjon. Det var planer om å lage et konsollverktøy, men jeg er ikke sikker på om det er nødvendig?
Resultatet?
En liten og enkel webserver for klargjøring av flere telefonmodeller med API for administrasjon.
Igjen, hvordan skal dette fungere?
- Installerer sonate.
- Vi lager en json-konfigurasjon og publiserer den i sonata.
- Så mottar vi en klargjøringslenke fra sonata.
- Da angir vi denne lenken i telefonen.
- Enheten laster inn konfigurasjonen
Det er bare to trinn i etterfølgende operasjon:
- Vi lager en json-konfigurasjon og publiserer den i sonata
- Enheten laster inn konfigurasjonen
Hvilke telefoner vil bli markedsført?
Leverandører Grandstream, Fanvil, Yealink. Konfigurasjonene i leverandøren er mer eller mindre de samme, men kan variere avhengig av fastvaren - det kan være nødvendig å teste i tillegg.
Hvilke regler kan du sette?
Etter tid. Du kan spesifisere tidspunktet før konfigurasjonen skal være tilgjengelig.
Etter mac-adresse. Når du sender inn konfigurasjonen via enhetens personlige lenke, vil også mac-adressen bli sjekket.
Av ip. Etter IP-adresse der forespørselen ble gjort.
Hvordan samhandle med sonate?
Via API, gjør http-forespørsler. API-en vil være tilgjengelig i installasjonen din. Fordi API-en støtter swagger-spesifikasjonen, du kan bruke for testforespørsler til API.
Ok flott. Kule ting, hva med å prøve det?
Den enkleste måten er å distribuere et docker-bilde basert på et depot . Depotet inneholder installasjonsinstruksjoner.
Hva om jeg kjenner node.js?
Hvis du har erfaring med å bruke JavaScript, vil du raskt finne ut hvordan alt fungerer her.
Blir det en Sonata-utvikling?
Jeg nådde delvis målene mine. Videreutvikling er et spørsmål om mine oppgaver innen temaet automatisering av telefonoppsett. Det er også en mulighet til å utvide konfigurasjonene for å konfigurere telefonknapper, legge til adressebokklargjøring, kanskje noe annet, skriv i kommentarfeltet.
Oppsummering og anerkjennelser
Jeg vil gjerne ha konstruktive forslag/innvendinger/kommentarer og spørsmål, fordi... Det kan godt hende at han beskrev noe uforståelig.
Jeg uttrykker også min takknemlighet til alle kollegene mine som hjalp, ga råd, testet og ga/donerte telefoner til tester. I virkeligheten er det mange jeg kommuniserte med på jobben som er involvert i prosjektet i ulik grad, e, i chatter og e-poster. Takk for ideene og tankene.
Kilde: www.habr.com