Docker में Playwright कैसे चलाएँ: 3 वितरण पैटर्न

TL;DR:

• Docker में Playwright के तीन व्यावहारिक डिप्लॉयमेंट पैटर्न हैं। आधिकारिक इमेज का उपयोग करें, एक नियंत्रित ब्राउज़र इमेज बनाएं, या टेस्ट रनर को एक कंटेनर में रखें और ब्राउज़र को Scrapeless Scraping Browser पर ले जाएं।
• Playwright पैकेज और ब्राउज़र इमेज को एक रिलीज़ लाइन पर सहमत होना चाहिए। पैकेज/इमेज मिलान की कमी ग्राहक को ब्राउज़र एक्सीक्यूटेबल की तलाश में छोड़ सकती है जो इमेज में उपलब्ध नहीं हैं।
• Chromium को एक कंटेनर में स्पष्ट प्रोसेस और मेमोरी प्रबंधन की आवश्यकता होती है। एक इनीट प्रोसेस चलाएँ, Chromium को पर्याप्त साझा मेमोरी दें, और अविश्वस्त पृष्ठों के लिए सैंडबॉक्स को बनाए रखें।
• एक कस्टम इमेज तब अपने रखरखाव की लागत को अर्जित करती है जब फ़ॉन्ट, प्रमाण पत्र, सिस्टम पैकेज या ब्राउज़र नीति को कलाकृति में ठीक करने की आवश्यकता होती है। अन्यथा, आधिकारिक इमेज सरल आधारभूत है।
• एक रिमोट क्लाउड ब्राउज़र एप्लिकेशन इमेज से ब्राउज़र बाइनरी को हटा देता है। Playwright कोड CI में रहता है जबकि Scrapeless क्लाउड ब्राउज़र और क्षेत्रीय एग्रेस का संचालन करता है।
• शुरू करने के लिए मुफ्त। नए Scrapeless खातों में मुफ्त Scraping Browser रनटाइम शामिल है — app.scrapeless.com पर साइन अप करें।

परिचय: Playwright का कंटेनरीकरण का मतलब ब्राउज़र का कंटेनरीकरण है

Playwright कोड एक छोटा Node.js डिपेंडेंसी है; ब्राउज़र और उनके Linux पुस्तकालय भारी हिस्सा हैं। एक कंटेनर जो केवल पैकेज को इंस्टॉल करता है वह सफलतापूर्वक निर्माण कर सकता है और फिर भी Chromium शुरू होने पर विफल हो सकता है क्योंकि एक्सीक्यूटेबल, फ़ॉन्ट, साझा पुस्तकालय, सैंडबॉक्स अनुमतियाँ, या साझा मेमोरी गायब हैं।

इसलिए डिप्लॉयमेंट विकल्प वास्तुशिल्प है। आधिकारिक इमेज Playwright को एक तैयार किए गए ब्राउज़र वातावरण से जोड़ती है। एक कस्टम इमेज आपको ऑपरेटिंग सिस्टम पर नियंत्रण देती है। एक रिमोट ब्राउज़र एप्लिकेशन कंटेनर को टेस्ट या निकासी कोड पर केंद्रित रखता है और ब्राउज़र संचालन को एक अलग सेवा में ले जाता है।

यह गाइड Playwright 1.62.0 की तीनों पैटर्न की तुलना करती है, जो आधिकारिक इमेज पर पिन की गई संस्करण है और सत्यापन के दौरान लोड की गई है।

Playwright कंटेनरों में क्यों टूटता है

Docker में Playwright आम तौर पर पांच सीमाओं में से एक पर विफल होता है।

आधिकारिक Playwright Docker गाइड तैयार की गई इमेज, संस्करण मिलान, --init, साझा मेमोरी, और अविश्वस्त पृष्ठों के लिए अलग-उपयोगकर्ता मॉडल का दस्तावेजीकरण करती है।

तीन डिप्लॉयमेंट पैटर्न एक नज़र में

केवल इमेज के आकार के आधार पर चयन न करें। ब्राउज़र सुरक्षा, उन्नयन स्वामित्व, समवर्तीता, पृष्ठ विश्वास, कलाकृति पुनरुत्पादन, और क्या ब्राउज़र को टेस्ट रनर से अलग नेटवर्क एक्सेस की आवश्यकता है, को ध्यान में रखें।

पूर्व आवश्यकताएँ

• एप्लिकेशन प्रोजेक्ट में Node.js 20।
• Playwright 1.62.0 में package.json।
• पहले दो पैटर्न के लिए Docker।
• रिमोट-ब्राउज़र पैटर्न के लिए एक Scrapeless खाता और API कुंजी।
• एक अनुमोदित परीक्षण लक्ष्य या सार्वजनिक पृष्ठ।

नोट: सत्यापन वातावरण में Docker स्थापित नहीं है, इसलिए नीचे दिए गए Docker बिल्ड और कंटेनर कमांड पूर्वाभिलाषा की कमी हैं। सटीक Playwright और Scrapeless SDK पैकेज स्थापित किए गए थे; एक स्थानीय Chromium पृष्ठ सफलतापूर्वक लोड हुआ, और SDK का Playwright.connect निर्यात कॉल करने योग्य के रूप में पुष्टि की गई थी।

विकल्प 1 — आधिकारिक Playwright इमेज का उपयोग करें

आधिकारिक इमेज उस स्थिति में सबसे अच्छा आधारभूत है जब कंटेनर विश्वसनीय एंड-टू-एंड परीक्षण करता है और आपको ऑपरेटिंग-सिस्टम कस्टमाइज़ेशन की आवश्यकता नहीं है।

पैकेज और इमेज को एक ही Playwright रिलीज़ लाइन में पिन करें:

FROM mcr.microsoft.com/playwright:v1.62.0-noble

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .

USER pwuser
CMD ["node", "check.mjs"]

इसे एक इनीट प्रोसेस और स्पष्ट IPC नीति के साथ बनाएं और चलाएं:

docker build -t playwright-check:1.62.0 .
docker run --rm --init --ipc=host playwright-check:1.62.0

लक्ष्य विश्वास मॉडल को स्पष्ट रखें। एक रूट-रन ब्राउज़र बिना अपने सैंडबॉक्स के नियंत्रित आंतरिक परीक्षणों के लिए स्वीकार्य हो सकता है, लेकिन यह मनमाने पृष्ठों के लिए डिफ़ॉल्ट नहीं है। NIST एप्लिकेशन-कंटेनर सुरक्षा गाइड इमेज उत्पत्ति, रनटाइम कॉन्फ़िगरेशन, मेज़बान नियंत्रण, और कार्यभार पृथक्करण को अलग परतों के रूप में मानता है।

विकल्प 2 — एक नियंत्रित ब्राउज़र इमेज बनाएं

कस्टम इमेज तब फायदेमंद होती है जब ब्राउज़र को संगठन प्रमाण पत्र, भाषा फोंट, मीडिया पुस्तकालय या एक आधार वितरण की आवश्यकता होती है जो प्लेटफ़ॉर्म के बाकी हिस्से से मेल खाता है।

सबसे छोटा स्पष्ट Dockerfile एक समर्थित Debian आधार से शुरू होता है और Playwright से ब्राउज़र और इसके ऑपरेटिंग-सिस्टम निर्भरताओं को स्थापित करने के लिए कहता है:

FROM node:20-bookworm

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
RUN npx playwright install --with-deps chromium

RUN useradd --create-home --shell /usr/sbin/nologin runner \
    && chown -R runner:runner /app
USER runner

COPY --chown=runner:runner . .
CMD ["node", "check.mjs"]

उत्पादन में घनत्व द्वारा Node आधार को पिन करें और जब ब्राउज़र पैकेज बदलता है तो इसे फिर से बनाएं। इमेज अब आपकी टीम की है: सुरक्षा स्कैनिंग, प्रमाण पत्र, फोंट, ब्राउज़र अपडेट, और बेस-इमेज रीफ्रेश सभी आपके रिलीज़ प्रक्रिया में चले जाते हैं।

साझा मेमोरी, सैंडबॉक्स, फ़ॉन्ट, और PID 1

कंटेनर की स्थिरता Chromium के चारों ओर रनटाइम अनुबंध पर निर्भर करती है।

साझा मेमोरी। Chromium रेंडर प्रक्रिया के लिए साझा मेमोरी का उपयोग करता है। यह तय करें कि पीसी या /dev/shm नीति को तैनाती कॉन्फ़िगरेशन में खोजने के बजाय, लोड के तहत रेंडरर बंद होने के बाद पता लगाया जाए।

सैंडबॉक्स। अविश्वसनीय पृष्ठों को गैर-रूट उपयोगकर्ता के रूप में चलाएं और ब्राउज़र सैंडबॉक्स को बनाए रखें। Linux seccomp एक प्रक्रिया के लिए उपलब्ध सिस्टम कॉल्स को सीमित कर सकता है; Linux seccomp फ़िल्टर दस्तावेज़ उस कर्नेल सीमा का वर्णन करता है।

फोंट और स्थानीयता। एक ब्राउज़र कार्यात्मक रूप से स्वस्थ हो सकता है जबकि गलत लाइन ब्रेक, गायब ग्लिफ़ या स्क्रीनशॉट के भिन्नताएँ उत्पन्न करता है। केवल उन भाषा पैक को स्थापित करें जो परीक्षण अनुबंध की आवश्यकता है और छवि सत्यापन के दौरान एक प्रदर्शक ग्लिफ़ को सत्यापित करें।

PID 1। Chromium बच्चे प्रक्रियाएँ बनाता है। एक init प्रक्रिया को संकेत प्राप्त करना चाहिए और बच्चों को समाप्त करना चाहिए। Open Container Initiative रनटाइम कॉन्फ़िगरेशन ने उन प्रक्रियाओं और Linux रनटाइम क्षेत्रों को परिभाषित किया है जिन्हें एक अनुपालन अवयव राइनटाइम उपयोग करता है।

Scrapeless के साथ स्क्रैपिंग प्रारंभ करें

Scrapeless के साथ अपनी वेब स्क्रैपिंग और स्वचालन कार्यप्रवाह को शक्ति प्रदान करें!
आज ही साइन अप करें और $5 का मुफ्त क्रेडिट प्राप्त करें — कोई क्रेडिट कार्ड की आवश्यकता नहीं।

अपने मुफ्त क्रेडिट को Scrapeless Dashboard पर अब दावा करें।

विकल्प 3 — ब्राउज़र को कंटेनर से बाहर ले जाएं

एक रिमोट क्लाउड ब्राउज़र Playwright क्लाइंट को ब्राउज़र प्रक्रिया से अलग कर देता है। CI इमेज Node.js, परीक्षण कोड, और क्लाइंट पुस्तकालय को बनाए रखता है; प्रबंधित ब्राउज़र Chromium, ब्राउज़र निर्भरताएँ, सत्र जीवनचक्र, और क्षेत्रीय ब्राउज़र ईग्रेस का मालिक होता है।

इंटरफ़ेस सत्यापन के दौरान उपयोग किए गए समान पैकेज स्थापित करें:

npm install playwright@1.62.0 @scrapeless-ai/sdk@1.11.0

नोट: नीचे दिया गया कोड आपके Scrapeless API कुंजी की आवश्यकता है। पैकेज आयात और Playwright.connect इंटरफ़ेस को स्थानीय रूप से निष्पादित किया गया था, लेकिन क्रेडेंशियल-फ्री वातावरण क्लाउड सत्र नहीं बना सका।

import { Playwright } from "@scrapeless-ai/sdk";

const browser = await Playwright.connect({
  sessionName: "container-runner",
  sessionTTL: 300,
  proxyCountry: "US",
});

const context = browser.contexts()[0];
const page = await context.newPage();
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
console.log(await page.title());
await browser.close();

अब अनुप्रयोग इमेज को एक ब्राउज़र बाइनरी या इसके Linux पुस्तकालयों की आवश्यकता नहीं है। यह युग्मन को कम करता है, लेकिन यह एक नेटवर्क सीमा को पेश करता है: CI गुप्त भंडार में API कुंजी को रखें, आउटबाउंड पहुंच को सीमित करें, अनुमोदित क्षेत्र का चयन करें, और प्रत्येक सत्र को स्पष्ट रूप से बंद करें।

स्क्रैपिंग ब्राउज़र क्विकस्टार्ट, उत्पाद पृष्ठ, और मूल्य निर्धारण को पढ़ें, इससे पहले कि आप एक उत्पादन कार्यभार स्थानांतरित करें।

CI/CD और स्केलिंग चेकलिस्ट

• Playwright पैकेज, ब्राउज़र इमेज, और लॉकफ़ाइल को एक साथ पिन करें।
• जब पैकेज/इमेज रिलीज़ लाइनें भिन्न होती हैं तो निर्माण विफल करें।
• पूर्ण सूट से पहले एक धूम्रपान नेविगेशन चलाएं।
• अविश्वसनीय पृष्ठों के लिए गैर-रूट ब्राउज़र उपयोगकर्ता का उपयोग करें।
• जानबूझकर init, IPC, CPU, मेमोरी, और एपhemeral स्टोरेज को कॉन्फ़िगर करें।
• CI गुप्त भंडार में और परतों या निर्माण लॉग से बाहर क्रेडेंशियल्स रखें।
• स्वीकृत क्षेत्र के अलावा अन्य छत की अनुमति न दी जाए जब तक कि मालिक ने दूसरी छत को मंजूरी नहीं दी।
• ब्राउज़र, पैकेज, इमेज, क्षेत्र, और परीक्षण संशोधन को नौकरी के परिणाम के साथ रिकॉर्ड करें।

Playwright प्रॉक्सी और क्लाउड-ब्राउज़र गाइड प्रॉक्सी नीति और दूरस्थ कार्यान्वयन के लिए इसी अलगाव को बढ़ाता है।

कैसे चुनें

आधिकारिक इमेज का उपयोग करें जब आप पुनरुत्पादनीय CI के लिए सबसे छोटा मार्ग चाहते हैं और लक्षित पृष्ठों को नियंत्रित किया जाता है। एक कस्टम इमेज बनाएं जब ब्राउज़र निर्भरताएँ आपके अनुप्रयोग के परीक्षण किए गए उत्पाद का हिस्सा हों। जब ब्राउज़र बाइनरीज़ अनुप्रयोग इमेज में नहीं रहनी चाहिए या जब ब्राउज़र स्तर को स्वतंत्र क्षेत्रीय और क्षमता नियंत्रण की आवश्यकता होती है, तो Scrapeless Scraping Browser का उपयोग करें।

एक हाइब्रिड सामान्य है: निर्धारक आंतरिक परीक्षणों के लिए एक छोटा आधिकारिक-इमेज कार्य रखें और अनुमोदित सार्वजनिक-web यात्राओं को एक प्रबंधित क्लाउड ब्राउज़र पर भेजें। महत्वपूर्ण विकल्प यह है कि प्रत्येक कार्य वर्ग के लिए ब्राउज़र जीवनचक्र का स्वामित्व किसके पास है।

निष्कर्ष: ब्राउज़र को स्पष्ट सीमा के पीछे रखें

Docker में Playwright तब भविष्यवाणी करने योग्य बनता है जब पैकेज, ब्राउज़र, ऑपरेटिंग सिस्टम, और रनटाइम नीति को एक अनुबंध के रूप में माना जाता है। आधिकारिक इमेज उस अनुबंध को प्रदान करती है। एक कस्टम इमेज आपको इसे स्वामित्व देने की अनुमति देती है। एक दूरस्थ क्लाउड ब्राउज़र इसे अनुप्रयोग कंटेनर के बाहर ले जाता है।

उस सीमा का चयन करें जो पृष्ठ विश्वास, रखरखाव क्षमता, और स्केलिंग आवश्यकताओं के साथ मेल खाती है, फिर हर रिलीज़ के हिस्से के रूप में सीमा को पिन और परीक्षण करें।

क्या आप Playwright इन्फ्रास्ट्रक्चर को सरल बनाने के लिए तैयार हैं?

हमारे समुदाय में शामिल हों ताकि एक मुफ्त योजना का दावा कर सकें और उन डेवलपर से कनेक्ट हो सकें जो CI में ब्राउज़र ऑटोमेशन चला रहे हैं: Discord · Telegram.

app.scrapeless.com पर मुफ्त Scraping Browser रनटाइम के लिए साइन अप करें और एक छोटे CI रनर से रिमोट-ब्राउज़र पैटर्न का परीक्षण करें।

सामान्य प्रश्न

प्रश्न: क्या आधिकारिक Playwright इमेज प्रसंस्करण CI के लिए पर्याप्त है?

आधिकारिक Playwright इमेज एक मजबूत बुनियाद है जब उसकी रिलीज़ लाइन प्रोजेक्ट पैकेज से मेल खाती है और रनटाइम नीति लक्षित के विश्वास स्तर से मेल खाती है। उत्पादन में अभी भी इमेज स्कैनिंग, सीक्रेट्स प्रबंधन, संसाधन सीमाएँ, और नौकरी-स्तरीय सबूत की आवश्यकता होती है।

प्रश्न: Playwright स्थानीय स्तर पर क्यों काम करता है लेकिन Docker में विफल होता है?

कंटेनर में अपेक्षित ब्राउज़र निष्पादन फाइल, साझा पुस्तकालय, फॉन्ट, साझा-मेमोरी नीति, सैंडबॉक्स अनुमतियाँ, या बच्चे-प्रक्रिया प्रबंधन की कमी हो सकती है। चयनकर्ता या प्रतीक्षा बदलने से पहले उन सीमाओं की जांच करें।

प्रश्न: क्या Playwright कंटेनर को Chromium सैंडबॉक्स को अक्षम करना चाहिए?

एक कंटेनर जो अप्रत्याशित पृष्ठों पर जाता है, को ब्राउज़र सैंडबॉक्स को बनाए रखना चाहिए और एक उपयुक्त गैर-रूट उपयोगकर्ता के रूप में चलाना चाहिए। केवल एक नियंत्रित विश्वास मॉडल के लिए एक कमजोर सैंडबॉक्स का उपयोग करें जिसे आपकी सुरक्षा टीम ने अनुमोदित किया है।

प्रश्न: क्या दूरस्थ Playwright को अभी भी एक प्रॉक्सी की आवश्यकता है?

ब्राउज़र स्तर को अभी भी एक अनुमोदित एग्रेस नीति की आवश्यकता है। Scrapeless Scraping Browser 195+ देशों में आवासीय प्रॉक्सी संलग्न कर सकता है; परीक्षण या डेटा अनुबंध द्वारा आवश्यक देश को पिन करें।

प्रश्न: जब लक्षित DOM बदलता है तो क्या होता है?

धूम्रपान यात्रा को पुनः चलाएँ और भूमिका-आधारित लोकेटर, पृष्ठ राज्य, और प्रस्तुत आउटपुट की जांच करें। कंटेनर स्वास्थ्य चयनकर्ता स्थिरता की गारंटी नहीं देता।

प्रश्न: क्या एक होस्ट के खिलाफ कितने Playwright कार्यकर्ता चलने चाहिए?

एक होस्ट प्रति तीन कार्यकर्ताओं से अधिक न रखें जब तक कि साइट के मालिक ने किसी अन्य सीमा को अनुमोदित नहीं किया है। ब्राउज़र क्षमता को लक्ष्य-होस्ट समवर्ती से स्वतंत्र रूप से बढ़ाएँ।

प्रश्न: क्या यह तैनाती बिना एक AI एजेंट के चल सकती है?

हाँ। तीनों पैटर्न सीधे मानक Playwright कोड चलाते हैं। एक AI एजेंट वैकल्पिक है और यह पैकेज, कंटेनर, ब्राउज़र, या अधिकृत सीमाओं को नहीं बदलता है।