Conectați OPC UA la Docker

Înainte de a începe

• Un volum persistent pentru directorul PKI. Aceasta este întreaga lecție a acestei pagini.
• O decizie privind numele de gazdă al containerului și ApplicationUri, pentru că niciunul nu se rezolvă așa cum o face pe un laptop.
• Accesibilitate de rețea de la container către portul 4840 de pe servere, inclusiv orice firewall de gazdă de pe gazda containerului însăși.

Configurarea

1. Montați directorul PKI pe un volum denumitOricum i-ar spune stiva dumneavoastră - ./pki, căile depozitului de configurare de securitate sau folderul rădăcină al managerului de certificate - montați-l. Identitatea containerului se află acolo și trebuie să supraviețuiască unei reporniri.
2. Setați explicit ApplicationUriNu îl lăsați să ia implicit o valoare derivată dintr-un nume de gazdă aleatoriu al containerului. Setați-l în configurație și asigurați-vă că aceeași valoare apare ca intrare de tip URI în SAN-ul certificatului.
3. Puneți în SAN-ul certificatului fiecare nume accesibilNumele de serviciu al containerului, numele DNS al gazdei și orice adresă pe care o va apela efectiv un partener. Un client care compară URL-ul apelat cu SAN-ul nu are nicio treabă cu ce crede containerul că îl cheamă.
4. Tratați timpulContainerele moștenesc ceasul gazdei. Un ceas al gazdei deviat produce eșecuri de timp al certificatului pe certificate perfect valide, așa că NTP pe gazdă este un control de securitate.
5. Demonstrați cazul de repornire înainte de livrarePorniți containerul, stabiliți o sesiune securizată, reporniți containerul și confirmați că sesiunea se restabilește fără ca un administrator să atingă o listă de încredere. Dacă nu se întâmplă asta, volumul nu este montat unde credeți.
6. Expuneți portul corect pentru un serverUn server OPC UA containerizat are nevoie ca portul 4840 să fie publicat, iar URL-ul endpointului pe care îl anunță trebuie să fie unul la care clienții pot ajunge cu adevărat - nu adresa sa internă de container.

Cum arată spațiul de adrese

Containerizarea nu schimbă spațiul de adrese. Ce schimbă sunt identitatea și accesibilitatea: certificatul, ApplicationUri și URL-ul de endpoint anunțat. Acestea trei sunt întreaga diferență dintre o implementare funcțională și una derutantă.

Capcanele

• Un volum PKI nepersistent este cel mai frecvent mod de eșec al OPC UA în containere. Simptomul este exasperant: funcționează, apoi eșuează după fiecare deploy, cu o eroare de certificat care arată ca o modificare făcută pe server.
• Un server containerizat care își anunță numele de gazdă intern al containerului în descrierea endpoint-ului dă clienților un URL pe care aceștia nu îl pot rezolva. Configurați explicit numele de gazdă anunțat.
• Devierea ceasului gazdei produce eșecuri de timp al certificatului care arată ca probleme de conținut al certificatului. Verificați ceasul înainte de a reconstrui un certificat.
• Fișierele temporare și intermediare din interiorul containerului sunt în regulă, dar tot ce trebuie păstrat - certificate, exporturi de nodeset, configurație - are nevoie de un volum.
• Dacă containerul repornește frecvent sub un orchestrator, fiecare repornire înseamnă o conexiune nouă la fiecare server. Eșalonați pornirea, altfel vă construiți propria furtună de conectări.

Cum scoateți date OEE din el

Nimic direct - aceasta este instalație de implementare. Contează pentru OEE doar în sensul că un colector care pierde încrederea la fiecare implementare produce goluri în datele dumneavoastră de disponibilitate, iar un gol în colectare nu se poate distinge de timpul de nefuncționare decât dacă înregistrați separat starea de sănătate a colectorului. Publicați un semnal de colector-online alături de datele mașinii.

Verificat ultima dată la 7 septembrie 2026 față de OPC UA 1.05.07. OPC UA Connect este o resursă educațională și nu este afiliată cu OPC Foundation.