Web Tips Plus: 2月 2019

Dockerで立てたCollabora Onlineのコンテナが動いていないようなので、

$ docker stop コンテナ名
$ docker start コンテナ名

のようにコンテナを再起動してみたが、以下のようなエラー...

/usr/bin/docker-current: Error response from daemon: driver failed programming external connectivity on endpoint コンテナ名 : COMMAND_FAILED: '/usr/sbin/iptables -w2 -t nat -A DOCKER -p tcp -d 127.0.0.1 --dport 9980 -j DNAT --to-destination 172.17.0.2:9980 ! -i docker0' failed: iptables: No chain/target/match by that name..

そこで、以下のコマンドでDockerを再起動してみた。

$ systemctl restart docker.service

再起動後、$ docker ps -a で確認するとコンテナが止まっていたので、

$ docker start コンテナ名

とすると、無事接続できた。

2019年2月13日水曜日

Docker 最も簡単なはじめかた

CentOS7のDockerイメージを取得します。

$ docker pull centos:centos7

CentOS7のDockerイメージからコンテナを作成して起動します。

$ docker run -it -d --name centos7 centos:centos7

　-it コンテナのプロセスにttyを割り当てる。

　-d コンテナをバックグラウンドで実行する。

　–name 作成するコンテナに名前をつけるオプション。

docker exec コマンドでコンテナ内のコマンドを実行する。

$ docker exec -it centos7 /bin/bash
[root@e735565de68a /]# ここからコンテナ内CentOS7のコマンドが実行できる

コンテナ内でexitするとコンテナが停止して元のコマンドに戻ります
[root@e735565de68a /]# exit

コンテナを起動したまま、元のコマンドラインにもどるには
"ctrl"を押した状態で"P、Q" （dettach）

再度コンテナにもどるには（attach）
$ docker attach centos7

コンテナの停止・起動

$ docker stop centos7

コンテナの一覧を表示させて停止したことの確認

$ docker ps -a

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e735565de68a centos:centos7 "/bin/bash" 2 hours ago Exited (137) 2 minutes ago centos7

停止したコンテナを再度起動

$ docker start centos7

せっかく作成・調整したものを削除してしまわないように保存します

作成したコンテナをイメージとして保存

$ docker stop centos7 (まず停止させます)

$ docker commit centos7 centos7new:centos7
※ $ docker commit 作成したコンテナ名新しい名前:タグ名

コンテナの削除（停止してから削除します）

$ docker stop centos7

$ docker rm centos7

Dockerイメージを削除する場合は

$ docker images (イメージを一覧表示させて確認)

$ docker rmi centos7 (イメージの削除)

※このコマンドはせっかく作ったイメージが削除されてしまうので、もう要らないときだけ使います。気をつけましょう。

参考

DockerでCentOS 7のイメージを利用してみよう | WEB ARCH LABO

https://weblabo.oscasierra.net/docker-centos7/

DockerでCentOS7起動時にsystemctlが動かないとき | GROUP DEV BLOG | TECHNO MOBILE

https://www.tcmobile.jp/dev_blog/devtool/docker%E3%81%A7centos7%E8%B5%B7%E5%8B%95%E6%99%82%E3%81%AEsystemctl%E3%81%8C%E5%8B%95%E3%81%8B%E3%81%AA%E3%81%84%E3%81%A8%E3%81%8D/

2019年2月12日火曜日

「Raspberry Pi」ベースのモジュラーデバイス「pi-top 4」

「Raspberry Pi」ベースのモジュラーデバイス「pi-top 4」--ガジェットの自作を容易に - TechRepublic Japan

https://japan.techrepublic.com/article/35131939.htm

2019年2月8日金曜日

JavaScript 独自セレクトボックス実装 Select2

Getting Started | Select2 - The jQuery replacement for select boxes

https://select2.org/

WordPress API化

《WordPress》2017年末にWP REST API で取得してVue.jsで描画するまでのまとめ。

https://qiita.com/uto-usui/items/4eb21aec704b888936d0

Headless CMSとWordPressの囚人 - Qiita

https://qiita.com/teradonburi/items/fd2c34a52c0c4cfd0d22

プログラマの採用面接で聞かれる、データ構造とアルゴリズムに関する50以上の質問 | POSTD

https://postd.cc/50-data-structure-and-algorithms-interview-questions-for-programmers/

2019年2月6日水曜日

RaspberryPiを産業用途に - BH3 | 株式会社ビズライト・テクノロジー

http://bh.bizright.co.jp/

電源スイッチがあるのは助かります。

サーバーエンジニアへの構築手順書

https://genchan.net/page-3454/

2019年2月5日火曜日

あまり知られていないBootstrapスタイルテクニック、小技16個まとめ - PhotoshopVIP

http://photoshopvip.net/69687

2019年2月4日月曜日

Raspberry Piをローテクで「便利」に使う！ | パソコン工房 NEXMAG

電子工作で、シャットダウンボタン追加
追加のモジュールで、起動・シャットダウン！
https://www.pc-koubou.jp/magazine/14369

2019年2月3日日曜日

Pythonで人工社会シミュレーション - Qiita

https://qiita.com/Keyskey/items/4cf57088841b3db1fb8b

2019年2月2日土曜日

Trilium Notes - 個人用ナレッジベース MOONGIFT

https://www.moongift.jp/2019/01/trilium-notes-%e5%80%8b%e4%ba%ba%e7%94%a8%e3%83%8a%e3%83%ac%e3%83%83%e3%82%b8%e3%83%99%e3%83%bc%e3%82%b9/

phpUploader - PHP製のファイルアップローダー MOONGIFT

https://www.moongift.jp/2018/11/phpuploader-php%E8%A3%BD%E3%81%AE%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%AD%E3%83%BC%E3%83%80%E3%83%BC/

2019年2月1日金曜日

Googleタグマネージャでクリックイベントを計測する3つの方法 | ウェブタタン

https://webtatan.com/blog/seo/tagmanager_click

WordPressをhttps化する方法とさくらサーバーでの注意事項 | ウェブタタン

https://webtatan.com/blog/wordpress/wordpress-https-sakura

ZOZOTOWN、画像データを Amazon S3 に移行

ZOZOTOWN、画像データを Amazon S3 に移行

販売商品数：常時65万点以上
日平均新着商品：3100点以上
ZOZOTOWNに掲載される商品画像：オリジナルサイズの画像とそのサムネイル画像の2種類
これらの画像を全10台以上のオンプレミスサーバで管理していた
移行の時点で保存していた商品画像は、オリジナル画像とリサイズ画像合わせて数億ファイルで、約60TB
商品画像は毎日数十万ファイルの規模でアップロード

画像の移行に当たって3つの方法を検討
1. 大量データ転送用ハードウェアの「AWS Snowball」を使って全画像を転送する方法
2. S3に直接全画像を転送する方法
3. S3にオリジナルサイズの画像のみ転送する方法

ZOZOTOWNが「Amazon S3」「AWS Lambda」で数億枚の商品画像を管理
その効果は：60TB以上の画像データをいかに管理するか - TechTargetジャパンクラウド
http://techtarget.itmedia.co.jp/tt/news/1812/26/news02.html#utm_medium=email&utm_source=tt-kn-friday&utm_campaign=20190201&utm_content=AL4

当初はSnowballを使った方法を検討していた。Snowballは大量の小容量ファイルをバッチ処理で圧縮せずに転送すると、オーバーヘッドが増加して転送速度が遅くなる特性がある。今回転送する一枚一枚の画像データは、平均128KBと小さい。この場合の転送速度は毎秒10MBになり、転送時間が72.8日かかることが判明した。柴田氏は「データを圧縮処理すれば転送速度は速くなるものの、圧縮処理にも時間がかかる」と説明する。さらにSnowballでの移行には暗号化処理のために、専用クライアントツールの「Snowball
クライアント」をインストールしたデバイスが必要で、暗号化処理とそのためのデバイスの準備、Snowball自体の手配など、転送以外にも準備時間がかかるのが難点だった。「Snowballを使うときは、ファイルサイズと内容について考慮する必要がある」（柴田氏）

オリジナル画像とリサイズ画像を含む60TB分の全画像を、直接S3に転送する方法はどうか。オンプレミスサーバからS3への転送処理には、AWSサービスの統合管理ツール「AWS
Command Line Interface」（CLI）と構成管理／変更管理サービスの「AWS
Config」を使用する。転送速度の実測値は毎秒42MBと、Snowballを利用したときの約4倍になり、推定転送時間は17.3日になった。新しくハードウェアを用意する必要がないため、予想準備時間もSnowballを使う方法より短縮された。

さらなる転送時間の短縮のために検討したのが、全画像データの総容量の半分であるオリジナル画像のみS3に転送し、その後サーバレスコンピューティングツール「AWS
Lambda」を用いて非同期処理でリサイズする方法だ。転送する画像のデータサイズが約60TBから約30TBとおよそ半分になるため、推定転送時間も8.6日と約半分に短縮された。転送の際にリサイズ用オンプレミスサーバが不要なこともメリットだった。ZOZOが商品画像のオンプレミスサーバからS3への移行方法として最終的に選んだのは、この方法だった。

移行後もLambdaで運用　クラウド移行の効果は

S3への移行後にアップロードされた新規画像のリサイズには、移行時に利用したのと同じLambdaを使用している。移行時に移行後と同じシステムを利用することで、膨大な画像の処理能力を事前に検証できるメリットを狙ったという。ユーザーが新規画像をS3の一次受けバケット（ファイルストレージ）にアップロードすると、Lambdaが画像をリサイズし、S3のオリジナル画像用バケットとリサイズ画像用バケットに分けて格納する（写真2）。

導入を検証していた当時の課題に、S3のGETリクエストの制限があった。当時のS3には秒間800リクエストの制限があったが、オンプレミスのサーバへのリクエスト数を測ったところ秒間795リクエストと上限に迫っていた。オリジナル画像とリサイズ画像でS3バケットを分けるなど、S3の構成を工夫することで改善したが、万全とは言えなかった。結果的には2018年7月に発表されたS3の性能向上によって秒間5500リクエストまでできるようになり、ひとまず考慮する必要がなくなった。

スケールアップの難しいオンプレミスサーバからS3へ移行したことで、増え続ける商品画像データの容量を気にせずシステムを運用できるようになった。バックアップサーバを含むオンプレミスサーバの管理からも解放された。画像関連のディスク修理やサーバのリプレース、夜間の保守作業がなくなったことで、保守管理コストを削減できたという。

リサイズにLambdaを利用することで、画像リサイズ用のサーバを用意する必要がなくなり、リサイズシステムの運用で管理しなければいけないものがコードのみになった。また柴田氏は「従来ずっと同じリサイズシステムを利用していたことによる、メンテナンスやチューニングなどの保守管理の属人化が解消された」と話す。

S3のGETリクエスト制限問題は解消されたものの、ZOZOTOWNのビジネス規模が急拡大した際には、同様の問題に直面する可能性はゼロではない。クラウドサービスは常に、個別のユーザー企業の要求を全て満たすわけではないからだ。それでも膨大なWebコンテンツのデータ管理について考えるとき、ZOZOTOWNのようなクラウドの導入は一つの選択肢となるのではないだろうか。

Vue.jsとFirebaseでOGP画像生成系のサービスを爆速で作ろう - Qiita

https://qiita.com/serinuntius/items/3017fb6ef51cd47352f6

登録: 投稿 (Atom)

2019年2月28日木曜日

2019年2月26日火曜日

2019年2月25日月曜日

2019年2月20日水曜日

2019年2月19日火曜日

2019年2月18日月曜日