LaravelをローカルのDockerで動かしていて、
画像の圧縮しようとしたときにつまずいたのでメモ。

エラー

GD Library extension not available with this PHP installation.

PHPのGDライブラリが使用できないらしい。
早速Dockerfileを編集

結論だけ言うと、このようなDockerfileになりました

FROM php:7.4-fpm
COPY php.ini /usr/local/etc/php/

RUN apt-get update \
  && apt-get install -y wget git unzip libzip-dev libpq-dev libfreetype6-dev libjpeg62-turbo-dev libpng-dev \
  && docker-php-ext-install zip pdo_mysql \
  && docker-php-ext-configure gd --with-freetype --with-jpeg \
  && docker-php-ext-install -j$(nproc) gd

#Composer install
COPY --from=composer /usr/bin/composer /usr/bin/composer

ENV COMPOSER_ALLOW_SUPERUSER 1

ENV COMPOSER_HOME /composer

ENV PATH $PATH:/composer/vendor/bin


WORKDIR /var/www

RUN composer global require "laravel/installer"

Dockerfileの変更を反映

イメージ：再構築の必要あり：docker-compose build
コンテナ：再構築の必要あり：docker-compose up -d

無事にエラーが出なくなりました。

開発環境にDockerを使うと環境構築などがかなり楽になると聞き、Docker-compose.ymlの書き方どころかDockerfileの書き方/読み方すらわからないにもかかわらずDockerを利用してRailsでアプリの開発を行っていました。（今はDockerの勉強もはじめDockerfileやdocker-compose.ymlについても徐々に理解できてきています）

そして開発中に毎回感じていたのが新たにGemを追加した後のdocker-compose buildなどでdocker-composeをタイプするのがめんどくさいということです。
dockerをdokcerやdocerなどとタイポしてエラーになることもしばしば。

そんななかQiitaでこちらの記事を見つけました。

インフラど素人が1ヶ月半でKubernetes本番環境を作るまでの失敗の軌跡（奇跡）

こちらの記事で「エイリアスは幸せ」という見出しがあり、そこで初めてエイリアスの設定で自分用のショートカットのようなものが作れるということを知りdocker-composeの呪縛から開放されました。

ちなみに私がエイリアスの設定で参考にしたのはこちらの記事です。

【コマンド】docker用のコマンドショートカット「alias」のおすすめ設定

私のようにdocker-composeのタイピングに苦労している初学者の方は是非参考にしてみてください。

まとめ

ウェブアプリを作りたかったため、Linuxの勉強はあまりしてこなかったのでこうした便利なコマンドの存在すら知りませんでした。

情報社会様様です。

Cloud Native Security Day 2020 参加記録

1. 参加概要

タイトル: Cloud Native Security Day
日時: 2020年8月17日(月)
場所: リモート参加

こちらの内容は当日発表を聞きながら取ったメモーですので、タイピングミスなどがあるかもしれないです。
当日の発表録画はYoutubeなどに公開する可能性があるので、CNCF公式ページをチェックしてみてください。

2. Talk1: Collection is not Detection

About Presenter ⇒ twitter @_sarahyo

2.1 Typical security operations issues

① Too many disconnected products.
② Not enought SOC analysts.
③ Too many disconnected products.
④ Environment are getting more and more complex.
⑤ Most SOCs depend on manual, time consuming processes.
⑥ Too many ALERTS.

2.2 How to run SecOps?

① Cloud-only.
② Hybrid.
③ On-prem.

2.3 What should we do?

① Collect logs from your entire application stack.
② Not just infrastructure, firewall, orchestrator, pods, application ...

2.4 Which can we use?

Which tools or products or vendors that can help me get the visibility i need for security operations?
・ Vulerability scanning.
・ SIEM.
・ Runtime security.
・ Auditing.
・ Policy tools.
・ Image repositoried.

2.5 When should we do?

① Watch all the time!!!!
② You need to iterate security operations throughout your entire environment life cycle!!!!
③ From creation > storage > deployment > runtime > teardown.

2.6 Others

You have mentioned about Mitre, where do we use them for Kubernetes ?
⇒ attack-matrix-kubernetes

3. Talk2：Establishing Image Provenance and Security in Kubernetes

About Presenter ⇒ twitter @adrianmouat

3.1 What is twilio?

Wikepedia： twilio

3.2 Notary v2

① Extension of Registry.
② Not another service to run.
③ Simple to start with.
④ Add more features, TUF etc later.

3.3 Tagging Images

① Treat production image tags as immutable.
② Git Hash.
③ Full version number.
④ Digest.

3.4 Annotations

① Defined in OCI Image Sped.
② Technically different to Labels.
③ Pre-Defined Annotation Keys.
④ Currently unsupported by build tools.
⑤ Just use Lables and predefined keys.

3.5 Metadata DB

① Store information on images.
② Keyed by digest.
③ Can be updated with events
④ Build data, contents and versions, kn.own vulns.

3.6 What about the Registry?

Would like to：
・ Search for all tags for digest.
・ Have audit information.
・ Plus other metadata.

3.7 Reproducible Container Builds

① Use tagged base images or digests.
② Version package installed software .
③ Run a mirror for total control.

3.8 Downloading Software

① Be careful when using curl/wget in Dockerfile.
② Use GPG to verify signatures - keys.openpgp.org.
③ Checksums.

3.9 Binary Reproducibility

① File timestamps.
② Other metadata.
・ Build container IDs.
・ Created timestamp.

3.10 Up-to-date vs Stable

① Tension.
・ Dont want breaking changes.
・ Do want bug-fixes.
② Good test suite.
③ Semantic versioning.
・ Pin to minor version (4.1.x).

3.11 Library Dependencies

Generally tooling available.
・ Maven display-plugin-updates.
・ NPM updtr.

3.12 Base Images

① Easy to use out-of -date base images.
② Constant rebuilds?
③ Hooks?

3.13 What should we do?

① Only run images from a controlled registry!!!
② Use immutable tags, labels, tools(Notary, registries, scanners...)

4. Talk3：Cloud Native or Cloud Agnostic ?

About Presenter ⇒ Sri Rajan

4.1 Cloud Agnostic Definitions

The term "cloud agnostic" is generally regarded to refer to applications and workloads that can be moves seamlessly between cloud platforms and between on-premises infrastructures and cloud platform.

4.2 Where do you draw the line ?

① It is not a zero-sum game. You can be in the middle.
② The further lower you go, the lowest common denominator you are.

4.3 What is the cost-benefit ratio ?

① Have you quantified it ? Even on the back of an envelope.
② Dont ignore opportunity cost.

4.4 Is your security responsibility the same ?

① You are accountable for your security.
② You are not alwasy responsible.

5. Talk4：How secure is your build/server?

About Presenter ⇒ twitter @patrickdebois

5.1 Secure Step

① Check what you execute
② Verify the checksums
③ Check your defaults
④ Is the Certificate still vaild ?
⑤ Who issued the certidicate ?
⑥ Is it an allowed CA ?
⑦ Is your dependency competent, reliable, sincere, care ?
⑧ Check the official name
⑨ Was transport secure ?
⑩ Do you trust your proxies ?

6. Talk5：

About Presenter ⇒ twitter @albcr

6.1 Many aspects of Kubernetes security

① Securing the control plane .
② Authentication, authorization, users.
③ Securing container images.
④ Monitoring, alerting.
⑤ Pod Security.

6.2 Pod Security

Configure security in your deployments.
① Limiting pod capabilities in the security context.
② Defining Pod Security Policies .
③ Defining RBAC rules.
④ Defining network policies.
⑤ Filtering system calls with seccomp.
⑥ Using non-root users.

6.3 Reality is different

① We conduct security assessments for customers.
・ Deployments already have PSP, network policies, etc.
② On big deployments, implementing security from scratch is difficult.
・ Understanding a new architecture is already difficult.

6.4 Fictive example

Source Code：GoogleCloudPlatform/microservices-demo

6.5 Security Lifecycle

① Record your apps behaviour
② Generate security policies
③ Review security policies
④ Add security policies as code

6.6 github：kube-psp-advisor

PsP = PodSecurityPolicy
① kubectl krew install advise-psp
② kubectl advise-psp inspect ...
・ Read resource from the apiserver
・ Aggregate information
・ Generate new resources
Source Code：sysdiglabs/kube-psp-advisor

6.7 github：oci-seccomp-bpf-hook

① Install on worker nodes
② Monitor syscalls from pods executed with the annotation:
　 io.containers.trace-syscall=of:/tmp/ls.json
③ Seccomp policy written in the specified file
Source Code：containers/oci-seccomp-bpf-hook

6.8 github：Inspektor Gadets Network Policy Advisor

① kubectl krew install gadget
② kubectl gadget network-policy monitor
③ kubectl gadget network-policy repport
・ Generate network policy (yamls)
Source Code：kinvolk/inspektor-gadget

7. Talk6：Defenders Think in Lists & Attackers Think in Graphs

About Presenter ⇒ Reuven Harrison - Tufin CTO

7.1 Why Lists

① Lists are easier to generate
② Most security audit tools produce lists of:
　 Vulnerabilities, Risky configurations, Failed benchmarks...
③ Security engineers rely on these lists
④ Problems:
・ Remediation requires collaboration with developers
・ Too many findings
・ How to prioritize?

7.2 Graphs reveal the path to the crown jewels

・ Initial access
・ Discovery (egress)
・ Lateral movement
・ Privilege escalation
・ Exfiltration

7.3 Tenets of s Useful Graph

・ Shows the risky paths combining:
　 - Network connectivity, vulnerabilities,
　 - RBAC, pod/container security
・ The wider scope:
　 - cloud, network, firewalls
・ Highlights top-priority problems
・ Not cluttered
・ Automatic, no setup and configuration
・ Guides the user

8. Talk7：K8S Attack and Defense:Inception Style

About Presenter ⇒ twitter @jaybeale

8.1 Demo

① Attack
・ RCE via Supply Chain issue
・ Monkey in the Middle Attack
・ Public Cloud API Attack
・ Pod Security Policy Evasion
② Defense Considerations
・ Software Supply Chain Work
・ Namespace Isolation or Policy
・ Workload Identity
・ OPA Gatekeeper

9. Talk8：New Paradigms for the Next Era of Security

About Presenter ⇒ twitter @sounilyu

9.1 Core Challenges and Solutions

① What did we buy and how does it support the biz ?
⇒ Asset Mgt, Systems Mgt Tools
② Viruses, Server-side Attacks, Insecure Configs
⇒ Anti-Virus, Firewalls, Secure Configs
③ Too many logs and alerts, Client-side attacks
⇒ IDS, SIEM
④ Assume Breach, Raging Fires, Too Many Privileges
⇒ Incident Responders & IR Tools (EDR, SOAR)
⑤ Ransomware, MBR Wiper, DDoS, Firmware Bricking
⇒ Distributed, Immutable, Ephemeral D.I.E Systems

9.2 2020s: Age of Recovery(or Resiliency)

• 1980: Identify
• 1990: Protect
• 2000: Detect
• 2010: Respond
• 2020: Recover

① Confidentiality ⇒ Wikileaks, Doxxing
② Integrity ⇒ Ransomeare, #fakenews
③ Availability ⇒ PDoS, MBR Wiper, Bricking Firmware

What kind of solutions directly support our ability to RECOVER or be RESILIENT?
- Serverless Architecture
- Copy on Write
- Content Delivery Network
- Docker
- Blockchain

9.3 DIE Triad

① Distributed ⇒ DDoS Resistant
　 The best solution against a distributed attack is a distributed service.
② Immutable ⇒ Changes Easier to Detect and Reverse
　 Unauthorized changes stand out and can be reverted to known good.
③ Ephemeral ⇒ Drives Value of Assets Closer to Zero
　 Makes attacker persistence hard and reduces concern for assets at rick

9.4 Fragility vs Resilience vs Anti-Fragility

Fragile C.I.A
⇒ Harm addressed through patches and workarounds that create greater fragility
Resilient D.I.E
⇒ Harm results in destruction but no change in configuration
Antifragile
⇒ Harm drives changes in configuration that make it even more D.I.E-like

e.g.
AWS Capabilities (Distributed + Immutable + Ephemeral)
⇒ Amazon Elastic Kubernetes Service, Amazon Elastic Container Service, AWS Fargate

9.5 others

① More irreversible attacks
② Insufficient against well-executed destructive/irreversible scenarios
③ Acoid pet creation and promote cattle creation

10. 感想

１日イベントとしては内容がなかなか多かったです。
どのシステム・サービスでもセキュリティ対策が大事ですので、このイベントを通して色んな対策と考え方を学習してきました。
システムを守ろうとする前に、まず自分が攻撃者になり、攻撃側の立場で考えることは今回のイベントの中で一番印象が残った内容です。
そして、Talk8のシステムリカバリー問題もなかなか興味深いので、もう少しそれについて調べたいと思います。
Kubecon+CloudNativeConの記録も後日投稿する予定するので、お楽しみに。

個人的な利用範囲でdockerを使っていると、ローカルでのデータ保存だけしておけば何ら苦労がなかったのですが、環境を移動することを想定してデータの保存を考えた時に、volumeマウントについて昔理解がなかなかできなかったので、volumeマウントを実感できるような方法を参考までに書いてみました。

volumeマウントを実感

volumeマウントを理解する時に個人的に良かった方法は、既存のコンテナを少しいじってそこから新たなイメージを作成するというやり方です。そしてこのコンテナを少しいじる方法を2つに分けることでvolumeマウントが理解できると思います。
今回はデフォルトで"Hello World"と出力されるコンテナを"あいうえお"と出力されるコンテナに変えていくという流れで説明をします。

方法

①volumeマウントをしてオリジナルイメージ作成
【流れ】

事前にindex.html("あいうえお")などを用意する。
↓
用意したindex.html("あいうえお")を起動中のコンテナにvolumeマウントする。
↓
volumeマウントされたコンテナから新規イメージを作成する。

②volumeマウントをしないで(直接上書き)オリジナルイメージ作成
【流れ】

起動中のコンテナにdocker execコマンドで入る。
↓
既存のコンテナ内にあるindex.html("hello world")を見つけ、それをechoコマンドで直接("あいうえお")に上書きをする。
↓
上書きをしたコンテナから新規イメージを作成する。

結果

①、②で作成された新規イメージは両方とも"あいうえお"と表示される予定です。しかし結果として、"あいうえお"と表示されるコンテナは②で作成されたコンテナであり、①ではデフォルトの"Hello World"が表示されてしまいます。

volumeマウントの注意点

なぜvolumeマウントをした①の新規のコンテナでは、"あいうえお"とでないのでしょうか。
それは、
【volumeマウントとは、あくまでマウントをされているのであり、コピーがなされているわけではない。つまりコンテナ内の変更は、コンテナ内に保存されるのでなくホスト側に保存がされている】
ということです。
そのため、【コンテナ内に変更を保存するためには、volumeマウントをするのではなく、直接コンテナ内にて上書きを行う】ということです。

※ちなみにコンテナ内のデータ保持の方法はたくさんありますが、今回はvolumeマウントを理解するためにこの比較方法を取りました。

このブログでは、アリババのエンジニアが、Docker、Kubernetes、そしてIstioのようなサービスメッシュやその他クラウドネイティブのあらゆるものについての考えや理解について語っています。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

Dockerについての考え

ここでは、Dockerの実践ガイドを読んだ後の感想を紹介します。

Dockerは、分散アプリケーションの構築、出荷、実行のために設計されたLinuxコンテナツールセットです。Dockerは、アプリケーションの分離と再利用性を確保するコンテナ化のプロセスや、物理マシンのセキュリティを確保するための機能的な方法である仮想化のプロセスを支援します。

多くの点で、Dockerはクラウドネイティブのパズルとなるものの最初の主流の1つでした。

下の図は、Dockerがどのように物事を効率化するために使用できるかを示したものです。

Dockerとは何か

以下のポイントは、Dockerとは何か、何をするのかをまとめたものです。

• Dockerは、アプリケーションのライフサイクル全体を連結する一種の契約と表現することができます。その中核的な強みは、アプリケーションの出荷を高速化し、全体的な生産性を向上させることです。
• Dockerは仮想マシンとは根本的に異なります。Docker、つまりコンテナ化の概念自体は仮想化ではありません。マシンのハードウェアをシミュレートしているわけでもありません。むしろ、Dockerはアプリケーションを中心に構築されており、オープンなdockerfile標準を使用して、設定や依存関係を含むアプリケーションをカプセル化しています。仮想マシンは、リソース管理に重点を置いてオペレーティングシステム層で動作します。
• また、DockerはChefやJenkinsと緊密に統合することができます。
• Docker Hubはコンテナイメージ管理の中心であり、Dockerアプリケーションの特徴を最もよく反映しています。各イメージは名前とタグ付けが可能で、固有のIDを持っています。

また、Dockerはアプリケーションのライフサイクルのすべてのステージとうまく統合されています。

• 開発：Dockerは、プロセスがその環境であることを考えると、開発環境の一貫性を確保し、Make、Chef、Puppetなどの従来の設定ツールと連携することができます。また、イメージが小さく、開発者に優しいのも特徴です。Dockerfilesを使用することで、ソースからイメージへの自動化を可能にします。
• DevOps：DockerはGitからDocker Hub、Jenkinsまでの自動化されたワークフローを可能にします。継続的なチェックイン、継続的なインテグレーション、継続的なデプロイ、継続的なデリバリーの包括的なワークフローを採用しています。
• 本番環境：Dockerは、SwarmやKubernetesなどのPaaS（Platform-as-a-Service）製品が輝く場所でもあります。

Dockerは以下のことを担当しています。

1、マルチホストコンテナのランタイムステータスと構成管理。
2、マルチホストおよびマルチコンテナのオーケストレーション環境におけるセキュリティ、ログ、トラブルシューティングの管理。

Kubernetesについて

以前にもほのめかしたように、Kubernetesはコンテナ化されたアプリケーションやDockerが普及し、コンテナを管理するプラットフォームとして利用され始めた後に登場しました。ここでは前回同様、Kubernetesの実践ガイドを読んだ後の反省点を発表します。

なぜKubernetesなのか

Kubernetesの人気はDockerと密接に関係しています。Dockerが広く適応したことで、Platform-as-a-Service（PaaS）が実現可能になりました。Kubernetesは、Googleで大規模なデータセンターの管理に多くの実務経験を積んだ後に生まれた偉大な成果です。また、当時起こったコンテナ化されたアプリケーションの爆発的な普及にも大きく後押しされました。Googleの目標は新しい業界標準を確立することでしたが、間違いなくそれを実現することが出来ました。

Kubernetesは本当にクラウドネイティブ革命の大きな一端を担っています。

Googleは2004年にコンテナの利用を開始し、2006年にはコントロールグループ（一般的にはcgroupsと呼ばれる）をリリースしました。同時に、BorgやOmegaなどのクラスタ管理プラットフォームをクラウドやITインフラで内部的に利用していました。KubernetesはBorgに触発され、Omegaを含むコンテナ管理者の経験と教訓を利用しています。

この魅力的な歴史については、このブログで詳しく読むことができます。

今後検討すべきことは、KubernetesはComposeやDocker Swarm、さらにはMesosのような他の初期の来訪者をどうやって打ち負かしたのでしょうか？この質問に対する答えは、簡単に言えば、Kubernetesの優れた抽象化モデルにあります。Kubernetesは原理的には設計の核心部分で異なっています。Kubernetesを理解するためには、その根底にあるアーキテクチャに関わるすべての概念と用語を俯瞰する必要があります。

Kubernetesの主な概念

以下に、多かれ少なかれKubernetes特有の概念を紹介します。Kubernetes の背後にある概念を理解することで、Kubernetes がどのように動作するかについてより一般的な理解を得ることができます。

• Pod: Podは、Kubertnetesアプリケーションの基本的な実行ユニットです。Podはいくつかのコンテナを組み合わせたもので、すべてが同じホスト上で実行され、同じネットワークネームスペース、IPアドレス、ポートを使用しています。これらのコンテナは、ローカルホストを使用して、お互いに通信したり、発見したりします。さらに、これらのコンテナは同じストレージボリュームを共有することができます。コンテナではなくPodは、Kubernetesの中で最も小さなユニットで、作成、スケジュール、管理を行います。Podは、より高い抽象度と、より柔軟なデプロイと管理モデルを提供します。

• コントローラー（Controller）：Controllerはタスク実行のためのロジックユニットで、負荷のスケジューリングや実行はController Managerで管理されます。ReplicationController（RC）はコントローラの特定の実装の1つで、弾力的なスケーリングとローリングアップグレードを担当します。各オブジェクトモデルには、ノード、サービス、エンドポイント、SA、PV、デプロイメント、ジョブなどの対応するコントローラがあります。また、拡張機能を使ってコントローラを実装することもできます。

• サービス：Kubernetesにおけるサービスとは、実際のアプリケーションサービスを抽象化したものです。Podにアクセスするための論理セットとポリシーを定義します。サービスはPodの単一アクセスポイント（またはプロキシ）として機能し、バックエンドのPodがどのように動作するかを知らなくてもアプリケーションにアクセスできるようにします。これにより、サービスのプロキシとディスカバリのメカニズムが簡素化され、拡張とメンテナンスが非常に簡単になります。サービスはPod以外にも、Kubernetesクラスタの外部サービスなど、任意のバックエンドのプロキシとして機能することができます。この場合、セレクタは必要ありませんが、サービスと同じ名前のエンドポイントを手動で定義する必要があります。

• ラベル（Label）：ラベルは、Podなどのオブジェクトに付けられるキー/値のペアです。ラベルは、Podをサービスやレプリケーションコントローラと緩く結合するために使用されます。

• ノード：Kubernetes用語でのノードとは、単にホストやマシンのことです。Kubernetesでは、ノードはワーカーマシンとして定義されており、仮想マシンであっても物理マシンであっても構いません。
  もっと詳しく知りたい場合は、ソース自体から入手したり、公式ドキュメントを直接読んだりすることができますが、それはここで見つけることができます。

Kubernetesと主流のCI/CDモデル

継続的インテグレーションとデプロイメントは、間違いなくPlatform-as-a-Service（PaaS）モデルの最も特徴的な特徴であり、同様にクラウドネイティブでもあり、ほとんどのクラウドベンダーはKubernetesをベースにしたPaaSモデルを提供しています。そのため、一般的なユーザーエクスペリエンスと、これらのモデルで使用される具体的なCI/CD（Continuous integration and continuous delivery）パイプラインが、異なるサービスを区別するものとなっています。一般的にCI/CDパイプラインは、プロジェクトが作成された時点で開始され、アプリケーションのライフサイクルの各段階に浸透します。これがCI/CDパイプラインの核心的な利点です。CI/CD パイプラインは、開発ワークフローのすべてのステップに統合することができ、オールインワンのアプリケーションサービス体験を提供します。

以下に、Kubernetesで使用できる主流のCI/CDツールをいくつか紹介します。

• Jenkins：Jenkinsはハドソンから出てきたもので、Javaで実装されています。おそらく現在最も広く使われているCI/CDツールです。
• TeamCity：TeamCityは、公開されている課題追跡やフォーラム、100種類のビルド構成など、強力な機能がたくさんあります。
• CircleCI: CircleCiは、安全な方法で大規模な開発プロセスを簡単に自動化したい場合に最適です。そのクライアントはFacebook、Kickstarter、Spotifyなどです。
• Travis CI： Travis CIは自信を持ってテストやデプロイを行うのに役立ちます。実際、Apacheのプロジェクトでは、統合テストにTravis CIを使用しています。各PRにはTCタスクがあり、ユニットテストを実行し、コードが仕様通りであることを確認します。
• Drone CI： Droneは、忙しい開発チームに便利なセルフサービスの継続的デリバリープラットフォームです。彼らのクライアントには、Cisco、Ebay、Gannett、VMWare、Capital Oneなどがあります。

Kubernetesで連携するAPIオブジェクトとメタデータ

さて、最後にKubernetesで重要なのは、Kubernetesと連携しているAPIオブジェクトとメタデータです。

• kuberctl：KuberctlはKubernetesのコマンドラインツールです。
• KubernetesのAPIに直接アクセス:Kubernetes API ServerはKubernetesのアクセスポイントです。RESTfulな操作をサービスし、Swaggerを統合してAPIを定義・記述します。詳しくはこちらをご覧ください。

• Kubebuilder SDK:KubebuilderはKubernetesのメインSDKです。
  実際には、メタデータはAPIオブジェクトの基本情報を定義するだけです。それはメタデータフィールドで表現され、以下の属性を持っています。

• namespace： namespacフィールドは、API オブジェクトの名前空間を指定します。namespaceフィールドは、APIオブジェクトの名前空間を指定します。名前空間は、Kubernetesがサポートする同じ物理クラスタにバックアップされた複数の仮想クラスタとして定義することができます。異なるプロジェクト、チーム、ユーザーは異なる名前空間を使用して、他のポリシー以外にも管理やカスタマイズされたアクセス制御を行うことができます。ノード以外のAPIオブジェクトはすべて名前空間に属します。これはmetadata.namespaceによって定義されます。このフィールドが定義されていない場合は、defaultと呼ばれるデフォルトの名前空間が使用されます。

• name: nameフィールドはAPIオブジェクトの名前を指定します。nameフィールドは重要な属性です。これは、metadata.nameAll API オブジェクトは、Node を除くすべての API オブジェクトが名前空間に属しています。同じ名前空間内では、これらのオブジェクトは名前で識別されます。したがって、APIオブジェクトの名前は、ネームスペース内で一意でなければなりません。ノードとネームスペースはシステム内で一意でなければなりません。

• ラベル：ラベルフィールドは、APIオブジェクトのラベルを指定します。ラベルは、APIオブジェクトに添付されるキー/値のペアです。ラベルは、オブジェクトの識別属性を指定するために使用することを意図しており、ユーザーにとって意味があり、関連性がありますが、コアシステムに直接セマンティクスを意味するものではありません。ラベルは、オブジェクトのサブセットを整理したり、選択したりするために使用することができます。ReplicationController と ReplicationService は、Podに関連付けるためにラベルを使用します。Podはラベルを使ってノードを選択することもできます。

• アノテーション:アノテーションフィールドは、API オブジェクトのアノテーションを指定します。アノテーションフィールドは、オブジェクトに任意の非識別メタデータを添付するために使用されますが、オブジェクトの選択には使用できません。アノテーションは、構造化または非構造化の長いデータであることができ、キー/値のペアでもあります。

サービスメッシュについて

ここでは、Kubernetes、Dockerに次ぐ本当に大きな存在であるService Meshについて、さっそく見ていきたいと思います。私にとって、Service Meshの核心的な強みはその制御機能であり、特にService MeshのIstioが特に輝く場所の一つです。

実際、このままIstioのモデルが標準化されて拡大していけば、コンテナ化されたアプリケーションのデファクトPaaS製品になるのではないか、と言いたいところです。とはいえ、ApacheのDubbo、Envoy、NGINX、さらにはConduitのサービスメッシュも統合の選択肢としては有効だと思います。

Istioは本当に優れた選択肢だと思うので、まずそれに焦点を当ててみましょう。

Istioとは？

サービスメッシュを理解するには、サービスメッシュの設計原理を理解する必要があります。Istioの設計原理とは何かを見てみましょう。一言で言えば、コンテナスケジューリングプラットフォームに実装する前に、サービスの抽象化モデルが先に来るということです。下の図を考えてみてください。

Istioとは何かについて詳しく知りたい方は、こちらの公式説明をチェックしてみてください。

一般的に言えば、Istioのサービスモデルは、サービスとそのインスタンスの抽象モデルを含んでいます。Istioは基礎となるプラットフォームから独立しており、プラットフォーム固有のアダプタを持ち、プラットフォームで見つかったメタデータから様々なフィールドをモデルオブジェクトに入力します。この中で、サービスは、他のサービスが参照するユニークな名前を持つアプリケーションのユニットであり、サービスインスタンスは、サービスを実装するPod、仮想マシン、コンテナです。サービスには複数のバージョンが存在する可能性があります。

次にサービスモデルです。各サービスは、完全修飾ドメイン名（またはFQDN）と、サービスが接続をリッスンしている1つ以上のポートを持ちます。サービスは、それに関連付けられた単一のロードバランサと仮想IPアドレスを持つことができます。また、サービスモデルにはインスタンスも含まれます。各サービスは1つまたは複数のインスタンスを持ち、サービスの実際の顕在化として機能します。インスタンスはPodのようなエンティティを表し、それぞれがネットワークのエンドポイントを持っています。

Istioの設計には、サービスのバージョンも含まれており、サービスの各バージョンは、特定のバージョンに関連付けられたラベルのユニークなセットによって区別されています。もう一つの概念がラベルで、これは特定のサービス・バージョンのインスタンスに割り当てられる単純なキー値のペアです。同じバージョンのすべてのインスタンスは、同じタグを持たなければなりません。Istioは、基礎となるプラットフォームがサービス・レジストリとサービス発見メカニズムを提供することを期待しています。

Cloud Nativeについて知っておくべきことをさらにご紹介

以上、Docker、Kubernetes、そしてIstioのようなサービスメッシュについての話をしてきた中で、一つ大きなことを省いてしまったのですが、それは「クラウドネイティブ」ということです。では、「クラウドネイティブ」とは何か？何を意味するのか、「クラウドネイティブ」になるためには何が必要なのか、様々な解釈がありますが、Cloud Native Computing Foundation（CNCF）によると、クラウドネイティブは以下のように理解できます。

クラウドネイティブの技術とソリューションは、クラウド上にスケーラブルなアプリケーションを構築して実行できる技術と定義することができます。クラウドネイティブは、DockerやKubernetesのようなコンテナ技術の開発に伴って生まれたもので、一般的にはステートレスであること、継続的なデリバリが可能であること、マイクロサービスが可能であることなどの特徴を持っています。

クラウドネイティブの技術とソリューションは、優れた耐障害性と管理の容易さを保証し、特にCI/CDパイプラインによる自動化の堅牢なシステムと組み合わせることで、あまり手間をかけずに強いインパクトを与えることができます。

今日では、CNCFによると、Kubernetesの使用を含むクラウドネイティブと "クラウドネイティブ "の概念がありますが、Kubernetesはパズルの唯一のピースではなく、むしろ始まりに過ぎません。伝統的なマイクロサービスソリューションであるDubboがCNCFの景観の一部となっている現在、これらのソリューションが提供するユニークな機能や機能に惹かれて、クラウドネイティブに惹かれる人が増えています。

言い換えれば、今日のクラウドネイティブの風景では、多くの意味で、クラウドネイティブはKubernetesから始まって、最後にはIstioのようなサービスメッシュソリューションを受け入れることになるかもしれません。このブログで見てきたように、最初はDocker、次にKubernetes、そして今はService Meshがあります。

アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ

やりたいこと

CakePHP4で開発しているWebアプリケーションをステップ実行したい。

環境

• MacBookPro(macOSCatalina10.15.5)
• PHPStorm2020.2
• docker desktop2.2.0.3
• cakephp4.1.2

設定

Docker関連

php:7.4-apacheのイメージにphp.iniが配置されていないのでローカルで作ってdocker-composeでマウントする。

/Docker/php/php.ini

[xdebug]
xdebug.idekey="PHPSTORM"
xdebug.remote_enable=1
xdebug.remote_autostart=1
; host.docker.internalはdockerのhostマシンのIPを解決
xdebug.remote_host=host.docker.internal
; デフォルトは９０００だが参考がどちらも9001だったので。
xdebug.remote_port=9001

作ったphp.iniをマウントする。
./Docker/php/php.ini:/usr/local/etc/php/php.iniの部分を元々のファイルに追記。

/docker-compose.yml

version: '3'
services:
  web:
    container_name: xxx
    build:
      context: .
      dockerfile: ./Docker/php/Dockerfile
    volumes:
      - .:/var/www/html:cached
      - ./Docker/php/php.ini:/usr/local/etc/php/php.ini
    environment:
      - APP_DEFAULT_LOCALE=ja_JP
      - APP_DEFAULT_TIMEZONE=Asia/Tokyo
      - DATABASE_HOST=xxx
      - DATABASE_USER=xxx
      - DATABASE_PASS=xxx
      - DATABASE_NAME=xxx
      - DATABASE_TEST_URL=xxx
    command: bash -c "sh docker-init-setup.sh && apache2-foreground"
    ports:
      - '5001:80'

Dockerfileにxdebugのインストールを追記。
RUN pecl install xdebug \
&& docker-php-ext-enable xdebugの部分。
peclって何？となる方はこちらを参考

FROM php:7.4-apache

ENV APACHE_DOCUMENT_ROOT /var/www/html/app/webroot
RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf \
&& sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf \
&& a2enmod rewrite

RUN apt-get update && apt-get install -y \
    libicu-dev \
    zip \ 
    unzip \
&& docker-php-ext-install -j$(nproc) intl \
&& docker-php-ext-install -j$(nproc) pdo_mysql

RUN pecl install xdebug \
    && docker-php-ext-enable xdebug

RUN ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

COPY . /var/www/html

ENV COMPOSER_ALLOW_SUPERUSER 1
COPY --from=composer /usr/bin/composer /usr/bin/composer

RUN cd ./app && \
    composer install --no-dev -o

上記を設定後に、以下を実行してxdebugを設定したコンテナを起動する。

docker-compose down
docker-compose up -d

PHPStrom

Preferences>Languages&Frameworks>PHP>Debugのポートを変更する。

Preferences>Languages&Frameworks>PHP>Serversを以下の設定にする。
Nameとhostは適当に。ローカルのappディレクトリとDocker上のappディレクトリをマッピングしている。

edit configurationsから以下の設定を追加する。

虫ボタンを実行する。

動作確認

適当なところにデバッグポインタを設定する。（行番号あたりをクリック）

通常通りのURLにブラウザでアクセスするとPHPStormの該当の箇所が選択された最前面に出てくる。（xdebug.file_link_format = phpstorm://open?%f@%lが必要かなと思ったけどなくて良さそう。）

http://localhost:5001/xxx

参考

以下でxdebugについて学んだ。
https://qiita.com/castaneai/items/d5fdf577a348012ed8af

以下でpeclについて学んだ。
http://dqn.sakusakutto.jp/2015/07/php_extension_pecl_phpize.html

以下で具体的な設定方法を学んだ。
https://qiita.com/gigosa/items/90431be7a6a79db78480
https://qiita.com/haruna-nagayoshi/items/99fa041e884c2c3975d2

大変参考になりました。
ありがとうございます。

このチュートリアルでは、Alibaba CloudのStarter Packageサービスを使ってDockerを使ってMagentoのeコマースサイトを設定する方法を紹介します。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

1. なぜアリババのクラウドでeコマースサイトを構築するのか

• Alibaba Cloud上にEコマースプラットフォームを構築すると、以下のようなメリットがあります。

• Alibaba Cloudは、毎日何百万人もの顧客にサービスを提供している世界No.1のeコマースサイトAlibaba.comをサポートしています。
  アリババクラウドは、世界200以上の国と地域に61のアベイラビリティゾーンを持つプレミアクラウドサービスです。これは、Alibaba Cloudを利用することで、顧客が要求するデータを最も近い利用可能なポイントから配信し、待ち時間の問題を解消することを意味しています。

• Alibaba Cloudは、CSA-STAR、SOC、PCI/DSS、GDPRなど、世界中のデータセンターに関連するいくつかの国際認証をサポートしています。このような認証により、Alibaba Cloud上で処理されるデータは、データセキュリティの国際基準のコンプライアンス要件を満たす最新のツールによって常に安全に保護されていることが保証されています。

• Alibaba Cloudは、Air Asia、Fordなど、世界的に認知されている多くの企業と提携し、クライアントに優れたサービスを提供しています。

2. 環境を整える

Eコマースサイトを構築するには、以下の要件を満たす必要があります。

• Alibaba Cloudアカウント。まだお持ちでない場合は、アカウントを設定してから次に進みます。
• インターネットに接続できるパソコン
• DockerとDocker Composeの基礎知識
• Ubuntu OS 16以上で動作する仮想マシン

3. Alibaba Cloud Starter Package 2.0

Alibaba Cloudのスターターパッケージは、シンプルで拡張性が高く、費用対効果の高いElastic Compute Service (ECS)を利用して、お客様のクラウドホスティングのあらゆるニーズに対応し、即座にサービスを開始することができます。新しいSSDクラウド・サーバー・パッケージは、使いやすく高性能な仮想マシンとより高いデータ転送プランを大幅な割引料金で提供し、月額2.50ドルからの利用を可能にします。14のグローバルリージョンで利用できるため、サーバーのデータセンターリージョンを簡単に選択して、特定の要件を満たすことができます。各ユーザーは、同時データ転送プランで最大5つのECSインスタンスを持つことができます。

4. ケーススタディ：スターターパッケージを使用してeコマースサイトを構築する方法

4.1. プロジェクトの概要

プロセスをよりよく理解するために、このチュートリアルでは、Magentoフレームワーク、Docker、Docker Compose、Alibaba Cloud Starter Packageを使用してEコマースウェブサイトを構築するシナリオを示します。

MagentoはPHPで書かれたオープンソースのeコマースプラットフォームです。トランザクションオプション、マルチストア機能、ロイヤルティプログラム、商品の分類とショッパーフィルタリング、プロモーションルールなどが含まれています。Dockerを使わずにMagentoをインストールすると、複数の設定が必要になるため、非常に複雑で、完了までに多くの時間がかかります。Dockerは、技術を非常に短い時間で立ち上げて実行できるようにすることで、開発者の生活を楽にしてくれます。スケーラビリティのために、多くのコンテナを同時に実行することができるので、Docker Composeは複数のコンテナを同時に実行するプロセスを支援します。

4.2. スターターパッケージを入手する

前項で述べたプロジェクトを実装するために、Starter Packageには以下のオプションがあります。

• 1 Core CPU
• 1 GB RAM
• 25 GB SSD
• 2 TB Data Transfer

上記の仕様でプランを選択するには、以下のステップを踏む必要があります。

ステップ1. アリババアカウントでログイン
アリババクラウドのホームページにアクセスし、画面右上の「ログイン」をクリックします。

ステップ2. Alibaba Cloudスターターパッケージインスタンスを購入する
ログインしたら、以下の画面からStarter Packageオプションを選択します。

ステップ2a.Starter Packageバンドルを選択したら、以下のように画面左下の「今すぐ購入」をクリックしてパッケージの購入に進みます。

ステップ2b.さて、以下のように「注文を確定する」をクリックして注文を確定します。

ステップ2c.次の画面で、ご注文を確認し、下記のように「お支払い」をクリックしてお支払いをしてください。

決済処理が完了すると、お祝いのメッセージが表示されたポップアップ画面が表示されます。

これで、購入したばかりのインスタンスを実行して、アプリケーションを構築、デプロイ、管理したり、プランに含まれるサービスを利用することができるようになります。

ステップ3.インスタンスの作成と選択
Starter Package Elastic Computing Service (ECS) インスタンスを購入した後は、コンテナ化された環境で Magento アプリケーションを実行できるインスタンスを作成して実行する必要があります。

そのためには、請求管理セクションに移動して、ECS インスタンスが実行されているかどうかを確認するために注文を確認する必要があります。管理リンクをクリックして、VNC や SSH クライアントを介して接続できるパブリック IP アドレスなどの仮想マシンの詳細情報を得ることができます。このプロジェクトのインスタンスのIPは47.74.218.106です。

ステップ4. インスタンスに接続する
VMのIPアドレスを取得したら、SSHでVMに接続し直します。ここではPuttyというソフトを使って実装します。以下は参考までにPuttyのログオン画面です。

SSH経由でリモートVMへの設定に成功すると、以下のような画面が表示され、VM内でMagento CMSを実行するために必要なコマンドをすべて実行できるようになります。

4.3. Magento のインストールとデプロイ

ステップ1. DockerとDocker Composeをインストールする
Docker Composeのインストールは非常に簡単です。まず、以下のコマンドを実行して、DockerのGitHubリポジトリからパッケージを取得します。

ステップ1a. Dockerをインストールする

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - 
$ echo "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable" | sudo tee -a /etc/apt/sources.list.d/docker.list 
$ apt-get update 
$ apt-get install docker-ce -y

ステップ1b. Docker Composeをインストールする

Docker Composeのパッケージをダウンロードしてインストールするには、以下のコマンドを実行する必要があります。

$ sudo curl -L https://github.com/docker/compose/releases/download/1.18.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

次に、set /usr/local/bin/docker-composeを実行ファイルとして以下のコマンドを実行してインストールします。

インストールが成功したかどうかを確認するには、コマンドを実行します。$ docker-compose --version. これでインストールされたバージョンが表示されます。

ステップ2. コンテナ化された環境でMagentoを実行する
YAMLファイルを自分で作成する代わりに、Dockerhub上にあるBitnamiが提供しているものを以下のコマンドでクローンすることができます。

$ curl -sSL https://raw.githubusercontent.com/bitnami/bitnami-docker-magento/master/docker-compose.yml > docker-compose.yml

.ymlファイルから引っ張ってきた画像を以下のコマンドで実行するだけです。

$ docker-compose up -d

ヒント:

• 上記のコマンドはデタッチドモードで実行されているため、コマンドがバックグラウンドで実行されている間もターミナルウィンドウを使用することができます。
• コンテナを停止したい場合は、docker-compose down コマンドを使用してください。
• ターミナル上で docker ps コマンドを実行すると、システム上のすべてのコンテナのリストを取得することができます。

注意：

• 上のスクリーンショットでは、コンテナ化された環境でMagentoを実行するには、bitnami/magentoとbitnami/mariadbを2つのコンテナで実行する必要があることがわかります。
• また、Magento サーバーは、サーバーのポート 80 (http) と 443 (https) で動作しています。したがって、これらのポート（デフォルトでは閉じられています）は、ウェブサーバ経由でアプリケーションにアクセスできるようにするために、VM上で開いておく必要があります。 ポート 80 と 443 を開きます。

デフォルトでは、セキュリティ上の理由からポート80と443は無効になっています。これらのポートを開くには、次の画面に示すように、デフォルトのセキュリティグループのポート22の設定を優先度1でクローン化する必要があります。

これで、コンテナが起動し、ポート80(http)と443(https)が開いています。これで、ブラウザを開いて http://47.74.218.106 にアクセスし、以下のページを見ることができるようになったことを意味しています。

アプリの起動に成功すると、以下のようなページが表示されるはずです。

あなたは今、あなた自身のストアを設定するようにMagentoの管理ページを訪問したい場合があります。そこで、あなたがしなければならないのは http://47.74.218.106/admin にアクセスして、以下の認証情報を使用してログインすることです。

ユーザー名：ユーザー
パスワード：bitnami1

ログインすると、Magentoの管理画面にアクセスできます。

N.B: IP アドレス 47.74.218.106 はインスタンスのパブリック IP であり、これはこのプロジェクトのために購入したばかりのインスタンスに固有のものであることに気づきましょう。したがって、購入するインスタンスによって異なることになります。

5. 次に行く場所

下記のように、多くの可能な最適化オプションが用意されています。

• 簡単にトラフィックのスパイクを処理するためにウェブサイトにロードバランサーを追加する
• 2つ以上のアベイラビリティゾーンにウェブサイトを展開する

結論

このチュートリアルで説明したすべての手順に従っていただければ、Docker Composeをシステムにインストールする方法、Docker Composeを使って複数のコンテナを実行する方法、そしてコンテナ化された環境にMagento CMSを正常にインストールする方法を理解していただけたと思います。

アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ

この記事は、作業の経過を書いておくことであとで同じようなことをする人の助けになればと思い書いています。経験がある人、もしくは未来人の私は助けてください。

Library Checkerを知っていますか？僕は知っています。

こんにちは。Library Checker（よすぽジャッジと呼んでいます）の言語にRubyを追加しようとして苦戦中です。

よすぽジャッジは競プロに必要なライブラリのテストができるサイトです。

現状、このサイトにはRubyのテスト環境はありません。残念ながら。

おそらくご存知ないと思いますが、私はRubyで競プロをすることに熱を（41.1℃ほども）入れているので、Rubyが使いたいのです。（諦めてRustに乗り換えようかとしていたのですが、Rubyをできるようにすればいいじゃないという私にとっては目からウロコの発想をくれたそすうぽよさんに感謝します）

どうにかRubyができるようにしたいので、がんばります。

とりあえず、先駆者様のプルリクを参考にしてみます。

• add Common Lisp #121
• add golang #86
• add csharp 8.0 #42
• Add C++17 support #17

なんとなくわかったような・・・・。

テスト環境を整えようとします。

problemsをcloneして、READMEを読みつつコマンドを打ってみます。

$ git clone https://github.com/yosupo06/library-checker-problems.git
$ cd library-checker-problems
$ ./generate.py -p unionfind
02:45:36 [INFO] Start unionfind
02:45:36 [INFO] generate params.h
02:45:36 [INFO] Test cases are already generated
02:45:36 [INFO] The checker is already compiled

よさげなのでjudgeをcloneして同様のことをします。

$ git clone https://github.com/yosupo06/library-checker-judge.git
$ cd ../library-checker-judge
$ pip3 install -r requirements.txt
$ ulimit -s unlimited
$ pip3 install termcolor toml psycopg2 psutil grpcio minio
$ sudo apt install postgresql-client libpq-dev python3 python3-dev python3-pip g++ cgroup-tools libcap2-bin
$ ./launch_local.sh

なんかエラーが出たので適当にぐぐって解決できないか試しました。エラーは消えたので覚えてません。

$ curl -OL https://github.com/google/protobuf/releases/download/v3.4.0/protoc-3.4.0-linux-x86_64.zip
unzip protoc-3.4.0-linux-x86_64.zip -d protoc3
$ sudo mv protoc3/bin/* /usr/local/bin/
$ sudo mv protoc3/include/* /usr/local/include/
$ pip3 install -U protobuf

./launch_local.sh

起動できたのでevansとやらを入れて試してみます。

# evans　インストール方法　わすれました
$ evans --host localhost --port 50051 api/proto/library_checker.proto
  ______
 |  ____|
 | |__    __   __   __ _   _ __    ___
 |  __|   \ \ / /  / _. | | '_ \  / __|
 | |____   \ V /  | (_| | | | | | \__ \
 |______|   \_/    \__,_| |_| |_| |___/

 more expressive universal gRPC client


librarychecker.LibraryCheckerService@localhost:50051>
Good Bye :)
evans: deprecated usage, please use sub-commands. see `evans -h` for more details.

いけたっぽい
あとjudge以下のGoも（↓いらないっぽい）

$ cd judge
$ go run main.go judge.go
2020/08/20 03:09:33 local mode
2020/08/20 03:09:33 Connect to API host: localhost:50051
2020/08/20 03:09:34 JudgeName: tzm
2020/08/20 03:09:34 Start Pooling

はい

この端末は開いたままで別の端末を起動して作業します。

どうやらいけたっぽいのでfrontendもやります。

$ git clone https://github.com/yosupo06/library-checker-frontend.git
$ go run . --local
[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.

[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:   export GIN_MODE=release
 - using code:  gin.SetMode(gin.ReleaseMode)

[GIN-debug] Loaded HTML Templates (12): 
    - login.html
    - navbar.html
    - problem.html
    - ranking.html
    - register.html
    - submitlist.html
    - 
    - css.html
    - help.html
    - problemlist.html
    - submitinfo.html
    - userlist.html

[GIN-debug] GET    /public/*filepath         --> github.com/gin-gonic/gin.(*RouterGroup).createStaticHandler.func1 (4 handlers)
[GIN-debug] HEAD   /public/*filepath         --> github.com/gin-gonic/gin.(*RouterGroup).createStaticHandler.func1 (4 handlers)
[GIN-debug] GET    /register                 --> main.registerGet (4 handlers)
[GIN-debug] POST   /register                 --> main.registerPost (4 handlers)
[GIN-debug] GET    /login                    --> main.loginGet (4 handlers)
[GIN-debug] POST   /login                    --> main.loginPost (4 handlers)
[GIN-debug] GET    /logout                   --> main.logoutGet (4 handlers)
[GIN-debug] GET    /                         --> main.problemList (4 handlers)
[GIN-debug] GET    /problem/:name            --> main.problemInfo (4 handlers)
[GIN-debug] POST   /submit                   --> main.submit (4 handlers)
[GIN-debug] GET    /submission/:id           --> main.submissionInfo (4 handlers)
[GIN-debug] GET    /submissions              --> main.submitList (4 handlers)
[GIN-debug] GET    /rejudge/:id              --> main.getRejudge (4 handlers)
[GIN-debug] GET    /ranking                  --> main.getRanking (4 handlers)
[GIN-debug] GET    /help                     --> main.helpPage (4 handlers)
[GIN-debug] GET    /admin/userlist           --> main.getUserList (4 handlers)
[GIN-debug] GET    /admin/addadmin/:name     --> main.getAddAdmin (4 handlers)
[GIN-debug] GET    /admin/deladmin/:name     --> main.getDelAdmin (4 handlers)
[GIN-debug] Listening and serving HTTP on :8080

いけたのかな？

なんかエラーが出てたので一旦終わってなんかします。

$ cd ../library-checker-judge/judge/executor-rust
$ cargo build --release

適当に全部再起動したらエラーでなくなりました。

ブラウザでlocalhost:8080を見てみます。

（スクショ撮るの忘れた）問題なんもねーじゃん。

$ cd ../library-checker-problems
$ ./deploy.py

はい。

おやすみなさい

Q. そんな行きあたりばったりで大丈夫か？
A. 大丈夫じゃないが