Налады проксі для запытаў S3 рэестра Distribution
Змесціце налады проксі ў працэс рэестра Distribution, які звяртаецца да S3, і асобна ўлічвайце кліентаў, перанакіраваных у сховішча аб’ектаў.
Для кантэйнерызаванага рэестра Distribution, які выкарыстоўвае HTTP-транспарт з улікам асяроддзя, перадайце маршрут S3 у кантэйнер рэестра:
services:
registry:
environment:
HTTP_PROXY: http://proxy.example.internal:8080
HTTPS_PROXY: http://proxy.example.internal:8080
NO_PROXY: localhost,127.0.0.1Аб’яднайце гэта з існуючымі image, сховішчам, аўтэнтыфікацыяй і volumes. Гэты фрагмент не з’яўляецца поўным рэестрам. Імя проксі павінна быць даступна з гэтага кантэйнера, а схема павінна адпавядаць слухачу проксі.
Пацвердзіце разгорнуты драйвер S3 і транспарт. Крыніца, на якую спасылаецца Distribution 2.8.3, выкарыстоўвае сесію AWS SDK; уласны драйвер або транспарт можа патрабаваць іншай падтрыманай канфігурацыі.
| Злучэнне | Хто наладжвае або даследуе |
|---|---|
| Кліент → рэестр | Уваходны HTTP-слухач рэестра і маршрут кліента |
| Daemon → крыніца image | Налады проксі Docker daemon |
| Рэестр → S3 | HTTP-транспарт сховішча працэса рэестра |
Паспяховы ўваход кліента даказвае толькі першы маршрут. Драйвер сховішча робіць уласныя запыты да S3; daemon, які раней загружаў image рэестра, гэтых выклікаў не робіць.
Праверце таксама перанакіраванні падчас загрузкі blob. Distribution можа перанакіраваць спажыўца ў сховішча аб’ектаў, што патрабуе ад гэтага кліента прамога доступу да S3. Налада проксі рэестра не наладжвае спажыўца. Змена паводзін перанакіравання змяняе шлях трафіку blob, таму вызначце крыніцу збою і аперацыю перад змяненнем гэтай налады.