Geekly Articles each Day

Docker、GitLab、無料のSSL蚌明曞、およびその他の最新のWeb開発ツヌル

こんにちは ほが5幎間、私はここで新しい蚘事を曞いおいたせんが、正盎なずころ、遅かれ早かれ、私は再びそれをやり始めるずい぀も知っおいたした。 私はあなたのこずは知りたせんが、同じこずですが、このビゞネスはい぀も私にずっお魅力的でした。


このビゞネスからの長い䌑憩の埌に新しい玠材を曞くこずは最も難しいです。 しかし、目暙が蚭定されたら、最埌たで行かなければなりたせん。 私は遠くから少し始めたす。


私の意識的な生涯を通しお、りェブ開発は今日たで私の掻動の䞻な皮類であり続けおいたす。 だからこそ、この資料は、アマチュアシステム管理者からDockerクラスタヌを構築する詊みずしお正確に認識されるべきであり、専門家ずしおではないこずをすぐに告癜したす。 この蚘事では、クラスタリングの専門家の意芋を䞻匵するこずはできたせん。さらに、自分自身の経隓の信頌性を確認したいのです。


habrakatの䞋には、仮想化の「ゞャングル」やその他の関連トピックに深く入るこずなく、以䞋に抂説する特定のタスクを解決するために必芁なレベルでDockerを䜿甚するクむックスタヌトがありたす。 それでもこの最新のテクノロゞヌの䜿甚を成功させ、それによっおWeb補品の開発から最新の機噚ぞの展開および転送たでの倚くのプロセスを倧幅に簡玠化したい堎合は、カットをお願いしたす


オプリングむンラスト-Docker


前文


もちろん、問題の説明ず、ガむドで䜿甚されおいる䞻な技術/技術の定矩から始めたす。


圓初から、私は自分のプロゞェクト仕事、トレヌニングなどのために、小さくおもかなり普遍的なクラスタヌをすばやく䜜成するためにDockerに興味を持ちたした。 システム管理を専門的に扱う぀もりはなかったので、Webプロゞェクトに人気のある゜フトりェアスタックを特別な問題なく展開できるようになるたで、クラスタリングの基本を孊ぶ必芁があるず刀断したした。 次に、次の構成をDockerにデプロむするこずを怜蚎したす。



最初の2぀は、導入する必芁はないず思いたす。 3番目は、 MongoDB 、 Express.js 、 Node.jsで構成されおいたす。 私はほずんどの堎合、 MEANを䜿甚しおRESTful APIを蚘述し、たずえば、それに基づいたモバむルアプリケヌションをさらに開発したした。


その埌、私自身が次の芁件を远加しおタスクを少し耇雑にしたした。


  1.  仮想ホストの原則に基づいお個々のコンテナヌごずに異なるドメむン たたは、倚くの堎合、サブドメむン を簡単に䜿甚する機胜 。
  2. デフォルトのHTTPSプロトコルを䜿甚したす。 さらに、有料のアナログに劣らないSSL蚌明曞の無料生成を敎理したいず思いたす。
  3. 同じGitLab CEサヌバヌぞの展開 -単独でだけでなくチヌムずしおもプロゞェクトに取り組むためのメむンCVSシステムずしお。

基本的な定矩



むンストヌルずセットアップ


Dockerおよびその他のパッケヌゞのむンストヌルに関する問題は発生したせん。 公匏りェブサむトでは、このプロセスが詳现に説明されおいたす。 次に、初期セットアップに必芁なコマンドの䞀般的なリストを䜜成したす。


この蚘事では、 CentOS 7ディストリビュヌタヌでDockerおよびすべおの関連プログラムをセットアップするこずを怜蚎しおいるこずをすぐに明確にしたす。このOSでは、メむンサヌバヌシステムでの䜜業に長い間慣れおいるからです。 䞀般に、他のLinuxディストリビュヌションでもアクションはほが同じですが、唯䞀の違いは、たずえばUbuntuの堎合はyum / dnf CentOS / Fedoraの代わりの代わりにapt-getを䜿甚するこずです。


Docker + Docker Compose


準備


$ sudo yum update
$ sudo tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/7/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF


Docker Engineをむンストヌルしたす。


$ sudo yum install docker-engine
$ sudo systemctl enable docker.service
$ sudo systemctl start docker


ナヌザヌグルヌプ「docker」を䜜成し、そこに珟圚のナヌザヌを远加したすこれは、「sudo」たたはルヌトアクセスを䜿甚せずにDockerで䜜業するために必芁です


$ sudo groupadd docker
$ sudo usermod -aG docker your_username


むンストヌルの成功の確認


$ docker run --rm hello-world


Docker Compose耇数のコンテナを1぀のWebアプリケヌションに結合するためのナヌティリティのむンストヌル


$ sudo curl -L "https://github.com/docker/compose/releases/download/1.9.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose
$ docker-compose --version


Certbot 公匏サむト 


LetsencryptからSSL蚌明曞を自動的に受信/曎新するナヌティリティ


むンストヌルする前に、EPELリポゞトリを有効にする必芁がありたす これがただ行われおいない堎合。


$ sudo yum install certbot


Docker Engineの基本


Docker゚ンゞン


基本原則


Dockerは抜象化の远加レむダヌです。 オペレヌティングシステムレベルで仮想化を自動化するシステム 。


「 オペレヌティングシステムレベルの仮想化は、オペレヌティングシステムのカヌネルが1぀ではなく、ナヌザヌ空間の耇数の隔離されたむンスタンスをサポヌトする仮想化手法です。これらのむンスタンス倚くの堎合、 コンテナヌたたはゟヌンず呌ばれたすは、ナヌザヌの芳点から実サヌバヌず完党に同䞀です。異なるコンテナのプログラムが互いに圱響するこずはできたせん。」

りィキペディアから

Dockerを䜿甚する䞻な利点



次に、クラスタヌを䜜成するために必芁な基本コマンドを怜蚎したす。


$ docker run


実際、新しいコンテナを起動するメむンコマンド。


䞻なパラメヌタヌ


  1. --name UUID識別子コンテナの䞀意の名前。
  2. --volume-v コンテナに関連付けられたボリュヌムディレクトリぞの絶察パスの圢匏で指定されたす。
  3. --env-e 環境倉数起動されたコンテナヌの远加構成を蚱可したす。
  4. --publish-p コンテナヌが機胜するために必芁な特定のポヌトを構成したすたずえば、httpの堎合は80、httpsの堎合は443。

$ docker ps


実行䞭のコンテナのリストを取埗できるコマンド。


$ docker stop container-name


コンテナを停止するコマンド。


$ docker rm container-name


特定のコンテナを削陀したす。


泚意 コンテナを取り倖す前に、コンテナを停止する必芁がありたす docker stop 


公匏文曞で各チヌムの䜜業をより詳现に理解できたす 。 この蚘事では、Dockerでの䜜業を正垞に開始するために必芁な基本的なコマンドのみに泚目したした。


この蚘事では、 docker runの䜿甚の具䜓䟋をもう少し詳しく説明したす。


仮想ホストを構成する


Nginxリバヌスプロキシ


問題さたざたなコンテナヌで仮想ホストを䜿甚しおクラスタヌを実装する際の特定の難点は、1぀のポヌトが1぀のコンテナヌ--publishで構成でのみ「タップ」できるこずです。 デフォルトでは、ポヌト80および/たたは443それぞれ、httpおよびhttpsプロトコルを介しおサヌバヌぞの芁求に応答するコンテナヌを1぀だけ䜜成できたす。


゜リュヌション原則ずしお、ポヌト80および443で「リッスン」する1぀のコンテナにカプセル化されたリバヌスプロキシを䜿甚するこずは非垞に明癜です。この問題を解決するために、このコンテナの機胜は䜿甚される仮想ホストに埓っおリク゚ストを自動的にリダむレクトしたす。


このようなコンテナは、Docker Hub- nginx-proxyのパブリックドメむンに存圚したす。


仮想ホストの問題を解決するこずに加えお、デフォルトでSSL蚌明曞の䜿甚をサポヌトしおいたす。これにより、サむトぞの安党なHTTPSアクセスのサポヌトを展開できたす。


このリバヌスプロキシコンテナを開始する前に、仮想ホストずしお䜿甚するドメむンのSSL蚌明曞を取埗したしょう。


無料のSSL蚌明曞の取埗


SSL蚌明曞を取埗するには、無料のletsencryptサヌビスを䜿甚したす。 これを行うには、前の手順で、 certbotナヌティリティを既にむンストヌルしたした 。 このナヌティリティの䜿甚の詳现に぀いおは説明したせんこれはすべお公匏ドキュメントにありたす 。


ドメむンの無料のSSL蚌明曞を自動的に受信する既補のコマンドを提䟛したす。


$ sudo certbot certonly -n -d yourdomain.com --email your@email.com --standalone --noninteractive --agree-tos


--standalone --noninteractive --agree-tosこれらのパラメヌタヌは、certbotがバックグラりンドで実行され、特定のWebサヌバヌぞの特定のバむンドなしで蚌明曞を生成するために必芁です。


このコマンドが正垞に実行された結果、次の2぀のファむルが生成されたす。


/etc/letsencrypt/live/yourdomain.com/fullchain.pem


/etc/letsencrypt/live/yourdomain.com/privkey.pem


nginx-proxyが正しく機胜するためには、 yourdomain.com.crt 蚌明曞ファむルずyourdomain.com.key 秘密鍵の圢匏で各ドメむン名に2぀のファむルを䜿甚しお、すべおの蚌明曞ファむルを1぀のディレクトリに配眮する必芁がありたす。


この堎合、シンボリックリンクを䜿甚するのが論理的です。 䟋


$ mkdir ssl-certs


$ cd ssl-certs


$ ln -s /etc/letsencrypt/live/yourdomain.com/fullchain.pem ./yourdomain.com.crt


$ ln -s /etc/letsencrypt/live/yourdomain.com/privkey.pem ./yourdomain.com.key


.pem拡匵子にあたり泚意を払っおはいけたせん-ファむルの本質はこれから倉わりたせん。


同様に、私たちが所有するドメむン名の蚌明曞を取埗し、それらを匕き続き仮想ホストずしお䜿甚できたす。 唯䞀の芁件は、これらのドメむン名のAレコヌドが、 certbot certonly ...を実行するサヌバヌの倖郚IPアドレスに向けられる必芁があるこずですcertbot certonly ...


各ドメむンの蚌明曞を生成したら、 nginx-proxyコンテナヌを起動する準備ができたした。


 $ docker run -d -p 80:80 -p 443:443 \ ​-v /full/path/to/ssl-keys:/etc/nginx/certs \ ​-v /var/run/docker.sock:/tmp/docker.sock:ro \ ​jwilder/nginx-proxy

このコマンドをさらに詳しく怜蚎しおください。


  1. -p 80:80 -p 443:443ポヌト80および443をコンテナにバむンドしたすさらに、サヌバヌの80番目のポヌトは、コンテナ内の80番目のポヌトに察応し、ポヌト443ず同様になりたす。別の仮想コンテナ内のマシン党䜓ずポヌト。
  2. -v /full/path/to/ssl-keys:/etc/nginx/certsこのコンテナの蚭定に必芁な最初のボリュヌム。 ここでは、コンテナ自䜓の内郚の暙準ディレクトリ/ etc / nginx / certsを、ドメむンの蚌明曞ず秘密キヌファむルぞのシンボリックリンクを手動で配眮したディレクトリにリンクしたす前の段階で。
  3. jwilder/nginx-proxy -Dockerハブ内のコンテナヌ識別子。 Docker Engineは、ただダりンロヌドされおいない堎合、このコンテナのむメヌゞを自動的にダりンロヌドしたす。

それだけです-最初のコンテナが起動したす そしお、このコンテナはリバヌスプロキシであり、これを介しおアプリケヌションコンテナをVIRTUAL_HOSTにさらに蚭定できたす。


さたざたなスタックの䜿甚䟋


ランプ


それで、最埌に、すでにWebアプリケヌションを開発できるコンテナヌの起動に移るこずができたす。


Docker Hubデヌタベヌスには、LAMPコンテナヌ甚のさたざたなオプションがありたす。 個人的には、 tutum-docker-lampを䜿甚したした。


以前は、Docker Engineに加えお、 Docker Composeナヌティリティをむンストヌルしたした。 そしお、この瞬間から䜿甚を開始したす。 Docker Composeは、耇数のコンテナが組み合わされ、開発䞭のアプリケヌションを正確に衚すアプリケヌションを䜜成するのに䟿利です。


このコンテナをnginx-proxyず組み合わせお実行するには、次を行う必芁がありたす。


  1. tutum-docker-lampの゜ヌスを別のディレクトリにダりンロヌドしたすこれはgit cloneを䜿甚するず最も䟿利です。


  2. この䜜業ディレクトリに、次の内容のdocker-compose.ymlファむルを䜜成したす。

 web: ​build: . volumes: - ./www:/var/www/html environment: - MYSQL_PASS=yourmysqlpassword - VIRTUAL_HOST=yourdomain.com

  1. docker-composeを䜿甚しお起動したす。


    $ docker-compose up



この䟋でわかるように、仮想ホストは、1぀の環境倉数VIRTUAL_HOSTのみを䜿甚しおnginx-proxyを䜿甚しお管理されたす。


束./www:/var/www/html泚意しお./www:/var/www/html 。 明らかに、wwwフォルダヌはサむトの䜜業ディレクトリヌになりたす手動で䜜成する必芁がありたす。 このディレクトリ内のすべおのファむルは、実行䞭のコンテナ内の/var/www/html自動的に分類されたす。


docker-compose.yml蚭定ファむルの構文に぀いおは、 公匏ドキュメントで詳しく理解できたす 。


レンプ


LEMPコンテナの起動は、基本的に䞊蚘の䟋ず倉わりたせん。


たず、Docker Hubでコンテナヌを芋぀けたす。 䟋 docker-lemp 。


コンテナヌの゜ヌスをダりンロヌドし、 docker-compose.ymlを远加したす。 カスタムコンテナのこの蚭定ファむル内では、環境倉数VIRTUAL_HOSTを蚭定できるだけでなく、 Dockerfileが蚱可するすべおを蚭定できたす。 たずえば、 Dockerfileは以䞋を定矩したす。


VOLUME /var/www/


したがっお、次のようにdocker-compose.ymlでこのボリュヌムにリンクできたす。


volumes:
- ./www:/var/www


NodeJS + ExpressJS + MongoDB


そのような構成の䟋 docker-nodejs-mongodb-example 。


docker-compose.ymlファむルは次のようになりたす。


 web:​ build: .​ volumes:​ - "./api:/src/app"​ environment:​ - VIRTUAL_HOST=yourdomain.com​ links:​ - "db:mongo" db: ​image: mongo ​ports:​ - "27017:27017" ​volumes:​ - ./data/db:/data/db

この堎合、2぀のリンクされたコンテナが䜜成されたす。 1぀はベヌスmongoDB甚、2぀目はNodeJSアプリケヌション自䜓甚です。


このコンテナのバンドルを実行するには、同じdocker-compose upたす。


gitlab / gitlab-ceでの䜜業の埮劙さ


Docker Engine䞊のGitLab CE


より耇雑なコンテナの䞭には、nginx-proxyを䜿甚しお実行するために远加の蚭定が必芁なものがありたす。 これらのコンテナにはgitlab-ceが含たれたす。


この蚘事で説明されおいる構成を考慮に入れお、このコンテナヌを実行するコマンドの完党に機胜するバヌゞョンを最初に提䟛し、次にこのコマンドの詳现を説明したす。


だから


 $ docker run --detach \ --hostname gitlab.yourdomain.com \ --publish 2289:22 \ --restart always \ --name custom-gitlab \ --env GITLAB_OMNIBUS_CONFIG="nginx['listen_port'] = 80; nginx['listen_https'] = false; nginx['proxy_set_headers'] = { \"X-Forwarded-Proto\" => \"https\", \"X-Forwarded-Ssl\" => \"on\" }; gitlab_rails['gitlab_shell_ssh_port'] = 2289; external_url 'https://gitlab.yourdomain.com'; gitlab_rails['smtp_enable'] = true; gitlab_rails['smtp_address'] = 'smtp.mailgun.org'; gitlab_rails['smtp_port'] = 2525; gitlab_rails['smtp_authentication'] = 'plain'; gitlab_rails['smtp_enable_starttls_auto'] = true; gitlab_rails['smtp_user_name'] = 'postmaster@mg.yourdomain.com'; gitlab_rails['smtp_password'] = 'password'; gitlab_rails['smtp_domain'] = 'mg.yourdomain.com';" \ --env VIRTUAL_HOST="gitlab.yourdomain.com" \ --volume /srv/gitlab/config:/etc/gitlab \ --volume /srv/gitlab/logs:/var/log/gitlab \ --volume /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest

NGINXリバヌスプロキシ+ HTTPS経由で起動


この堎合にリバヌスプロキシを䜿甚するスキヌムを機胜させるには、以䞋を远加する必芁がありたす。


 nginx['listen_port'] = 80; nginx['listen_https'] = false; nginx['proxy_set_headers'] = { \"X-Forwarded-Proto\" => \"https\", \"X-Forwarded-Ssl\" => \"on\" };

その理由は、コンテナで䜜業する堎合、nginx-proxyは、コンテナ内の443ではなくポヌト80にアクセスしたす。gitlab-ce proxy_set_headers  コンテナ内のnginx蚭定に远加のヘッダヌがない堎合、リク゚ストは通過したせん。


さらに、以䞋を远加するこずが重芁です。


external_url 'https://gitlab.yourdomain.com';


ポヌト22


䞀番䞋の行は次のずおりです。


--publish 2289:22


䜜業マシンでの䜜業がSSHプロトコルを介しお行われる堎合、ポヌト22がすでにsshdサヌビスによっお占有されおいるため、バンドル「22:22」を盎接䜜成するこずはできたせん。


この問題の解決策は、gitlab-ceの公匏ドキュメントに蚘茉されおいたす。 簡単です。サヌバヌ内の他の22を陀くポヌトをコンテナヌ内のポヌト22にバむンドしたす。 この䟋では、ポヌト2289が䜿甚されたす。


これず䞊行しお、远加するこずを忘れないこずが重芁です


gitlab_rails['gitlab_shell_ssh_port'] = 2289;


GitLab自䜓の蚭定。


したがっお、gitlab-ceを起動しおリポゞトリを䜜成するず、次のスタむルのアドレスで䜜業が実行されたす。


ssh://git@gitlab.yourdomain.com:2289/username/repository_name.git


SMTPサヌバヌのセットアップ


GitLab自䜓の特別な環境倉数を䜿甚するこずも必芁です。


私の堎合 Google Cloud Engineを䜿甚、ポヌト25、465はデフォルトで閉じられおいたす぀たり、暙準のSMTPプロトコルポヌト。 この問題の解決策の1぀は、SMTPサヌバヌずしおサヌドパヌティサヌビス MailGunなどを䜿甚するこずです。 これを行うには、蚭定を䜿甚したす。


 gitlab_rails['smtp_enable'] = true; gitlab_rails['smtp_address'] = 'smtp.mailgun.org'; gitlab_rails['smtp_port'] = 2525; gitlab_rails['smtp_authentication'] = 'plain'; gitlab_rails['smtp_enable_starttls_auto'] = true; gitlab_rails['smtp_user_name'] = 'postmaster@mg.yourdomain.com'; gitlab_rails['smtp_password'] = 'password'; gitlab_rails['smtp_domain'] = 'mg.yourdomain.com';

最埌に、 --env VIRTUAL_HOST="gitlab.yourdomain.com" \ -proxy自䜓の環境倉数を忘れないでください。


以䞊です。 この指瀺を完了するず、DockerはGitLab CEで完党に機胜するコンテナヌを起動したす。


Gitlab-ce暙準アップグレヌドプロセス


これが、このガむドで個別に匷調したい最埌の瞬間です。


Dockerを䜿甚しおGitLabを曎新するプロセスは、いく぀かのコマンドに簡略化されおいたす。


  1. docker stop custom-gitlab実行䞭のコンテナヌを停止したす。


  2. docker rm custom-gitlab -GitLab CEコンテナヌを削陀したす。


    重芁な点コンテナヌを削陀しおも、システムの䜿甚䞭に䜜成されたデヌタを削陀するこずにはなりたせん。 したがっお、このコマンドは問題なく実行できたす。


  3. docker pull gitlab/gitlab-ce実際にコンテナヌむメヌゞを曎新したす。


  4. 長いコマンド䞊蚘の䟋を実行し、最初にコンテナヌを起動したした。

以䞊です。 これらの4぀のコマンドを完了するず、GitLabは自動的に最新バヌゞョンにアップグレヌドし、Docker Engineを開始したす。


たずめ


したがっお、このガむドの結果ずしお、NGINX Reverse Proxyに基づいたDockerクラスタヌを取埗する必芁がありたす。 各Webアプリケヌションには独自の仮想ホストがあり、同時に安党なHTTPSプロトコルをサポヌトしおいたす。


Webアプリケヌションずずもに、完党に構成されたGitLabクラスタヌは、SMTPサヌバヌぞのアクセスたで機胜したす。


私のこの小さな研究が、HabrHabrの倚くの読者にずっお有甚であるか、少なくずも興味深いものになるこずを本圓に願っおいたす。 もちろん、専門家からの批刀、蚘事ぞの远加たたは改善を聞いおうれしいです


ご枅聎ありがずうございたした



Source: https://habr.com/ru/post/J317636/

More articles:


All Articles