Docker'ı web sitelerini kullanıcılar için ayırmak için kullanmak mümkün müdür?


12

Kullanıcıların FTP (bir hosting şirketi gibi) tarafından erişilebilen kendi web sitelerinin bulunduğu sunucuları yönetiyorum ve LAMP yığın işlemlerini izole etmek yerine Docker'ı uygulamanın ve web sitesi başına bir resim kullanmanın mümkün olup olmadığını merak ediyordum.

Anladığım kadarıyla, Docker örneğini bağlantı noktaları aracılığıyla gösterebilirsiniz, bu nedenle aynı sunucuda iki docker örneği çalıştırırsanız, iki farklı bağlantı noktasını açığa çıkarmanız gerekir.

Ancak portları değil, sunucu adını dışa aktarmak mümkündür:

  • www.somewebsite.com: Docker örneği 1
  • www.otherwebsite.com: Docker örneği 2
  • www.etc.com: Docker örneği ...

Ve bu, aynı sunucuda.

Sunucu adına göre özel Docker örneğine istek yönlendiren sunucuya yalnızca Apache yüklemeyi düşündüm, ancak daha sonra herhangi bir Docker örneğine Apache (tekrar!) Ve MySQL yüklemem gerekir.

Bu mümkün ve dahası, bu performans açısından ilginç mi (hiç de değil)?

Yardımın için teşekkürler.


1
Teorik olarak, Apache her Docker örneğinin dinlediği bağlantı noktasına doğru bir ProxyPass yapar.
thanasisk

Yanıtlar:


12

Evet mümkün. Yapmanız gereken 80 tane bağlantı noktası sağlamak. her URL için bir tane. Bunu Docker ana bilgisayar sunucusunda çalışan Apache Sanal Ana Bilgisayarı kullanarak yapabilirsiniz.

  1. DNS CNAME ayarlayın.
  2. Docker örneklerini çalıştırın ve 80 numaralı bağlantı noktalarını, docker ana bilgisayarının 12345 ~ 12347 numaralı bağlantı noktasına eşleyin.
  3. Docker ana bilgisayarında Apache sunucusunu çalıştırın ve her URL için bir Sanal Ana Bilgisayar ayarlayın ve ProxyPass ve ProxyPassReverse'i docker örneklerinizden biri olan localhost: 12345 olarak ayarlayın.

Apache yapılandırma dosyası şöyle görünecektir:

<VirtualHost *:80>
ServerName www.somewebsite.com
  <Proxy *>
    Allow from localhost
  </Proxy>
  ProxyPass        / http://local.hostname.ofDockerHost:12345/
  ProxyPassReverse / http://local.hostname.ofDockerHost:12345/
</VirtualHost>

4
Teşekkürler! Bu çok yardımcı oldu. Ayrıca, orada ProxyPreserveHost On, bu yüzden local.hostname.ofDockerHost: 12345 sitenizi sitenize çok fazla bağlantı ile bitmiyor . İşte bana yardımcı olan daha fazla bilgi: digitalocean.com/community/tutorials/…
tiangolo

Liman işçisi veritabanı vb. Değişiklikleri kaydedecek mi?
EminezArtus

3

Bu mümkün. Her bir kapsayıcıdaki apache bağlantı noktalarına yönlendirmek için ana sunucuda apache'yi (veya daha iyisi haproxy, nginx veya verniği, yalnızca bu yeniden yönlendirme görevi için apache'den daha etkili olabilir) kullanabilirsiniz.

Ancak, orada çalıştırdığınız sitelere (ve bunların apache yapılandırmalarına) bağlı olarak, özellikle çok fazla RAM gerektiren modülleriniz (yani php) varsa, sanal ana bilgisayarlarla tek bir merkezi apache kullanmaktan çok daha fazla bellek gerekebilir.


Cevabınız için teşekkür ederim. Gerçekten, ben sağlayacaktır "barındırma" hizmeti Prestashop, Wordpress, vb gibi şeyler içerir, bu yüzden, PHP ve ağır motorlar çok dayalı (Ben burada Prestashop hakkında daha fazla konuşuyorum).
Cyril N.

1
Dockerized sanal barındırma sistemi, PHP'yi kendi Docker kapsayıcılarına ayırarak ve Apache kapsayıcılarının bu kapsayıcıyı PHP işleme için kullanmasını sağlayarak daha iyi modüle edilebilir mi? Aynı veritabanları için de geçerli miydi? Örneğin, Apache kapsayıcılarına (kullanıcı web sitelerini içeren) ana bilgisayar proxy trafiği var, bu da tüm PHP işlemlerini bir PHP kapsayıcısına gönderir ve veritabanı bir MySQL kapsayıcısına okur / yazar. Veya PHP bu şekilde kaynaklara daha az aç kalır mı? PHP-FPM, SuPHP veya benzeri bir Docker olmayan ortamda aynı türden bir kurulum sağlar mı?
ojrask

Bir kapsayıcıdaki PHP-FPM en azından biraz gereksiz dosya alanı açısından olurdu: code.google.com/p/sna/wiki/NginxWithPHPFPM Apache / Nginx kurulumunun sırayla PHP dosyalarını PHP-FPM kapsayıcısına kopyalaması gerekir bu sistemin çalışması için. Takılı paylaşılan veri taşıyıcısı bu sorunu çözer mi?
ojrask

Kaplar arasında veri (yani php dosyaları) paylaşmanız gerekiyorsa, hacimler gitmenin yoludur, bunları diğer kapsayıcılardan (hatta ayrılmış veriler olsa bile) veya gerçek dosya sisteminden bağlayabilirsiniz. Apache modülü, php kodunu çalıştırmanın en hızlı yoluydu, statik dosyalara değil, sadece php için birine sahipti ve statik / önbelleğe alınabilir içeriği (yani vernik) sunmak için bir üst katmana sahipti, iyi bir kombo olabilirdi.
gmuslera

3

Bunun zaten yanıtlanmış olduğunu biliyorum, ancak bir adım daha ileri götürmek ve size daha eksiksiz bir cevap vermek için bunun nasıl yapılabileceğine dair bir örnek göstermek istedim.

Lütfen nasıl kullanılacağına dair talimatları içeren liman işçisi resmime bakın, bu size iki sitenin nasıl yapılandırılacağını gösterecektir https://hub.docker.com/r/vect0r/httpd-proxy/

Jihun'un dediği gibi, vhost konfigürasyonunuzu ayarladığınızdan emin olmanız gerekecektir. Örneğim, example.com test sitesini görüntülemek için 80 numaralı bağlantı noktasını ve example2.com test sitesini görüntülemek için 81 numaralı bağlantı noktasını kullanır. İçeriğinizi belirtmeniz ve Dockerfile dosyanızdaki gerekli bağlantı noktalarını göstermeniz gerekeceğini de unutmayın;

FROM centos:latest
Maintainer vect0r
LABEL Vendor="CentOS"

RUN yum -y update && yum clean all
RUN yum -y install httpd && yum clean all

EXPOSE 80 81

#Simple startup script to aviod some issues observed with container restart
ADD run-httpd.sh /run-httpd.sh
RUN chmod -v +x /run-httpd.sh

#Copy config file across
COPY ./httpd.conf /etc/httpd/conf/httpd.conf
COPY ./example.com /var/www/example.com
COPY ./example2.com /var/www/example2.com
COPY ./sites-available /etc/httpd/sites-available
COPY ./sites-enabled /etc/httpd/sites-enabled

CMD ["/run-httpd.sh"]

Umarım bu süreci biraz daha açıklamaya yardımcı olur. Bu konuda başka soru sormaktan çekinmeyin, yardımcı olmaktan mutluluk duyarız.

Saygılarımızla,

V


Ben de github bu görüntü yapmak için kullanılan dosyaları yükledim; github.com/V3ckt0r/docker-httpd-proxy
Vect0r

1

Benim durumumda SSLProxyEngine On , ProxyPreserveHost On ve RequestHeader eklemem gerekiyordu , docker kapsayıcısında SSL'yi etkinleştirmek istediğim için apache 2.4 vhost dosyama Front-End-Https "On" ayarladım . Hakkında local.hostname.ofDockerHost , benim durumumda liman işçisi kabı çalıştıran ana sunucunun adıydı Lucas ve liman işçisi konteyner limanına 443 eşleştirilmiş liman olduğu 1443 portu 443 konakta apache tarafından kullanılıyor olması nedeniyle ( sunucu), böylece bu satır bu şekilde sona erdi https: // lucas: 1443 /

Bu son kurulum ve gayet iyi çalışıyor!

<VirtualHost *:443> # Change to *:80 if no https required
    ServerName www.somewebsite.com
    <Proxy *>
        Allow from localhost
    </Proxy>
    SSLProxyEngine On # Comment this out if no https required
    RequestHeader set Front-End-Https "On" # Comment this out if no https required
    ProxyPreserveHost    On
    ProxyPass        / http://local.hostname.ofDockerHost:12345/
    ProxyPassReverse / http://local.hostname.ofDockerHost:12345/
</VirtualHost>

Son olarak, docker kapsayıcısında proxy SSL üstbilgileri ayarlamam gerekiyordu. Benim durumumda, konteyner nginx ve yakut uygulamaları kurmak için omnibus denilen bir şey çalıştırıyordu . Bunun bir nginx yapılandırma dosyasında da kurulabileceğini düşünüyorum. Birisinin bunu yararlı bulması durumunda olduğu gibi yazacağım

nginx['redirect_http_to_https'] = true
nginx['proxy_set_headers'] = {
    "Host" => "$http_host",
    "X-Real-IP" => "$remote_addr",
    "X-Forwarded-For" => "$proxy_add_x_forwarded_for",
    "X-Forwarded-Proto" => "https",
    "X-Forwarded-Ssl" => "on"
}
nginx['real_ip_trusted_addresses'] = ['10.0.0.77'] # IP for lucas host
nginx['real_ip_header'] = 'X-Real-IP'
nginx['real_ip_recursive'] = 'on'

Apache, ISS Config, Ubuntu sunucusu 16.04 için eksiksiz rehber burada https://www.howtoforge.com/community/threads/subdomain-or-subfolder-route-requests-to-running-docker-image.73845/#post-347744

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.