Menggunakan Docker selama proses pengembangan telah menjadi standar de facto. Meluncurkan aplikasi dengan semua dependensinya hanya dengan menggunakan satu perintah menjadi semakin umum. Jika aplikasi menyediakan akses menggunakan antarmuka-web atau API HTTP - kemungkinan besar wadah garis depan meneruskan portalnya yang unik (di antara aplikasi lain yang Anda kembangkan secara paralel) ke host, dengan mengetuk di mana kita dapat berinteraksi dengan aplikasi dalam wadah. .
Dan ini berfungsi dengan baik sampai Anda memiliki seluruh kebun binatang aplikasi, beralih di antaranya mulai menimbulkan ketidaknyamanan, karena Anda perlu mengingat skema dan port, dan di suatu tempat untuk memperbaiki port mana untuk aplikasi yang pernah Anda alokasikan, agar tidak Tabrakan muncul seiring waktu.
Dan kemudian Anda juga ingin memeriksa pekerjaan di https - dan Anda harus menggunakan sertifikat root Anda, atau selalu menggunakan curl --insecure ... , dan ketika berbagai perintah bekerja pada aplikasi - jumlah pasangan mulai tumbuh secara eksponensial.
Dihadapkan dengan masalah seperti itu sekali lagi - pikiran melintas di kepalaku "Hentikan!", Dan hasil pekerjaan pada beberapa akhir pekan adalah layanan yang menyelesaikan masalah ini sejak awal, yang akan dijelaskan di bawah. Untuk yang tidak sabar, secara tradisional - referensi .
Dunia Kami akan menyimpan proksi terbalik
Dengan cara yang baik, kita memerlukan semacam zona domain, semua sub-domain yang akan selalu diselesaikan oleh localhost (127.0.0.1). Pencarian cepat menunjuk ke domain dari formulir *.localho.st , *.lvh.me , *.vcap.me dan lainnya, tetapi bagaimana cara melampirkan sertifikat SSL yang valid kepada mereka? Setelah mengutak-atik sertifikat root, saya berhasil mendapatkan curl tanpa kesalahan, tetapi tidak semua browser menerimanya dengan benar, dan terus melempar kesalahan. Selain itu - saya benar-benar tidak ingin "dipusingkan" dengan SSL.
"Yah, mari kita pergi ke sisi lain!" - dan kemudian domain dengan nama localhost.tools dibeli, didelegasikan ke CloudFlare, resolusi yang diperlukan telah dikonfigurasi (semua sub-domain diselesaikan 127.0.0.1 ):
$ dig foo.localhost.tools | grep -v '^;\|^$' foo.localhost.tools. 190 IN A 127.0.0.1
Setelah itu, certbot diluncurkan dalam wadah, yang, setelah menerima API KUNCI dari CF menggunakan catatan DNS, mengonfirmasi kepemilikan domain, dan mengeluarkan sertifikat SSL yang valid pada output:
$ docker run \ --entrypoint="" \ -v "$(pwd)/cf-config.conf:/cf-credentials:ro" \ -v "$(pwd)/cert:/out:rw" \ -v "/etc/passwd:/etc/passwd:ro" \ -v "/etc/group:/etc/group:ro" \ certbot/dns-cloudflare:latest sh -c \ "certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials '/cf-credentials' \ -d '*.localhost.tools' \ --non-interactive \ --agree-tos \ --email '$CF_EMAIL' \ --server 'https://acme-v02.api.letsencrypt.org/directory' \ && cp -f /etc/letsencrypt/live/localhost.tools/* /out \ && chown '$(id -u):$(id -g)' /out/*"
File ./cf-config.conf berisi data otorisasi untuk CF, untuk lebih jelasnya, lihat dokumentasi untuk certbot, $CF_EMAIL - variabel lingkungan dengan email Anda
Oke, sekarang kami memiliki sertifikat SSL yang valid (bahkan selama 3 bulan, dan hanya untuk sub-domain dengan level yang sama). Tetap bagaimana cara memprosiasikan semua permintaan yang datang ke localhost di wadah yang tepat .
Dan di sini Traefik datang membantu kami (spoiler - itu indah). Dengan meluncurkannya secara lokal, meneruskan soket buruh pelabuhan ke wadahnya melalui volume - ia dapat mem-proxy permintaan ke wadah yang memiliki docker label diperlukan. Jadi, kita tidak memerlukan konfigurasi tambahan, kecuali ketika mulai menentukan label yang diinginkan untuk wadah (dan jaringan buruh pelabuhan, tetapi ketika memulai tanpa susunan buruh pelabuhan bahkan ini tidak diperlukan, meskipun sangat diinginkan), yang kami inginkan akses dengan nama domain dan dengan SSL yang valid !
Setelah melakukan semua cara ini, dunia melihat wadah buruh pelabuhan dengan sertifikat SSL Traefik dan wildcard yang sangat terkonfigurasi ini (ya, bersifat publik).
Kunci pribadi dari SSL dalam wadah publik?
Ya, tapi saya pikir ini tidak menakutkan, karena ini ada di zona domain, yang selalu menyelesaikan localhost. MitM dalam hal ini pada dasarnya tidak masuk akal.
Apa yang harus dilakukan ketika sertifikat memburuk?
Cukup cabut gambar segar dengan memulai kembali wadah. Proyek memiliki CI yang dikonfigurasi, yang secara otomatis, sebulan sekali (saat ini) memperbarui sertifikat dan menerbitkan gambar baru.
Saya ingin mencobanya!
Tidak ada yang lebih mudah. Pertama-tama, pastikan bahwa port lokal Anda 80 dan 443 gratis, dan lakukan:
Dan sekarang kita dapat menguji:
$ curl -sS http://my-nginx.localhost.tools | grep Welcome <title>Welcome to nginx!</title> <h1>Welcome to nginx!</h1> $ curl -sS https://my-nginx.localhost.tools | grep Welcome <title>Welcome to nginx!</title> <h1>Welcome to nginx!</h1>
Seperti yang Anda lihat, ini bekerja :)
Di mana dokumentasi tinggal, deskripsi?
Semuanya, tidak sulit ditebak, tinggal di https://localhost.tools . Selain itu, moncongnya responsif, dan dapat melihat apakah daemon proksi terbalik berjalan secara lokal dan menampilkan daftar wadah yang berjalan dan tersedia untuk interaksi (jika ada).
Berapa biayanya?
Tidak semuanya. Tentu saja Setelah melakukan hal ini untuk saya dan tim saya, saya menyadari bahwa ini dapat bermanfaat bagi pengembang / ops lainnya. Selain itu - hanya nama domain yang membutuhkan biaya, yang lainnya digunakan tanpa perlu pembayaran.
PS Layanan ini masih dalam versi beta, oleh karena itu - jika ada kekurangan, kesalahan ketik, dll - hanya mencoret - coret di PM . Hub "Pemrograman" dan "Pengembangan Situs Web" diindikasikan karena pendekatan ini mungkin berguna terutama di industri ini.