ហេតុអ្វីបានជា proxy សាជីវកម្មរបស់អ្នកកំពុងព្យាយាមដោះស្រាយឈ្មោះសេវា Compose
អតិថិជន HTTP អាចផ្ញើសំណើសេវាខាងក្នុងទៅ proxy ដែលបានកំណត់របស់ខ្លួន មុនពេលប្រើការដោះស្រាយឈ្មោះសេវារបស់ Docker។ បន្ថែមការបដិសេធដោយចេតនាសម្រាប់អតិថិជនត្រឹមត្រូវ។
កម្មវិធីឈានដល់អ៊ីនធឺណិតតាមរយៈ proxy សាជីវកម្មរបស់ខ្លួន ប៉ុន្តែ http://catalog:8080/ បរាជ័យ ហើយ proxy មិនអាចដោះស្រាយ “catalog” បានទេ។ សំណើនោះប្រហែលជាមិនដែលប្រើ DNS ខាងក្នុងរបស់ Docker ទេ។
អតិថិជន HTTP អាចជ្រើសរើស proxy របស់ខ្លួន មុនពេលបង្កើតការតភ្ជាប់ផ្ទាល់។ ពេលនោះ proxy ខាងក្រៅទទួលបានឈ្មោះដែលអត្ថន័យរបស់វាមានតែនៅក្នុងបណ្តាញ Compose ប៉ុណ្ណោះ។
- ប្រើឈ្មោះម៉ាស៊ីនក្នុងសំណើ។ សេវា Compose អាចរកឃើញតាមឈ្មោះសេវានៅលើបណ្តាញសមស្រប។ បន្ថែម
catalogទៅការកំណត់ការបដិសេធដែលគាំទ្រដោយអតិថិជនប្រើប្រាស់ ជំនួសឱ្យការសរសេរ IP កុងតឺន័រដោយថេរដែលអាចផ្លាស់ប្តូរ។ - រក្សាការលើកលែងដែលមានស្រាប់។ សម្រាប់អតិថិជនដែលដឹងពីបរិស្ថាន បញ្ចូលធាតុពាក់ព័ន្ធជាមួយបញ្ជីរបស់អង្គការ៖
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogពិនិត្យបណ្ណាល័យ ឬឯកសារប្រតិបត្តិពិតប្រាកដនៅក្នុងរូបភាព សម្រាប់ការគ្រប់គ្រងអក្សរធំតូច កំណែ និងវេយ្យាករណ៍ផ្គូផ្គង។ មិនមានឧបករណ៍ញែក NO_PROXY ជាសកលទេ។ កម្មវិធីឈ្មោះ wget នៅក្នុងរូបភាពតូច មិនចាំបាច់មានឥរិយាបថដូច GNU Wget ទេ។
នៅពេលសំណើជ្រើសរើសការបញ្ជូនផ្ទាល់ សូមពិនិត្យបណ្តាញរួមរបស់អ្នកហៅ និងសេវា សេវាដែលកំពុងស្តាប់ និងច្រកកុងតឺន័រ។ ច្រកម៉ាស៊ីនដែលបានផ្សព្វផ្សាយ គឺជាចំណុចបញ្ចប់មួយផ្សេងទៀត។ ការបដិសេធមិនអាចបន្ថែមការតភ្ជាប់បណ្តាញដែលខ្វះខាតបានទេ ដូចជាការបង្កើតបណ្តាញឡើងវិញមិនអាចបង្រៀន proxy ខាងក្រៅឈ្មោះ Compose ឯកជនបានដែរ។
រក្សាការបែងចែកដែលបានគ្រោងទុក៖ សំណើខាងក្នុងប្រើផ្លូវខាងក្នុងរបស់វា; សំណើខាងក្រៅរក្សា proxy ដែលបានអនុម័ត។ ការបិទ proxy ជាសកលអាចបិទបាំងការបរាជ័យមួយនេះ ខណៈពេលដែលដកផ្លូវដែលត្រូវការសម្រាប់សំណើខាងក្រៅបន្ទាប់។