What's New Qiita

20190710のGoに関する記事は5件です。

  • 投稿日：2019-07-10T19:24:14+09:00

s3オブジェクト一覧取得(Go)

はじめに

S3バケットのオブジェクト一覧を取得する場合は通常awscliを使用して

aws --profile {profile} s3 ls --recursive s3://{bucket}/{prefix}

のような感じで実行すると思います。
オブジェクトが少なければこれで問題ないですが、大量にあると時間がかかります。
実際に特定prefix配下の（1億ほど）オブジェクト一覧を取得する必要があり、awscliだと
数日かかることが見えていたので、Goで実装してどれだけ速くなるか試してみました。

コード

main.go
package main

import (
    "flag"
    "fmt"
    "os"
    "time"

    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/credentials"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/s3"
)

var (
    argRegion  = flag.String("region", "ap-northeast-1", "specify region name")
    argProfile = flag.String("profile", "", "specify credential profile name")
    argBucket  = flag.String("bucket", "", "specify bucket name")
    argPrefix  = flag.String("prefix", "", "specify object key prefix")
)

func main() {
    flag.Parse()
    defer func() {
        if r := recover(); r != nil {
            flag.Usage()
            fmt.Println(r)
            os.Exit(1)
        }
    }()

    config := aws.Config{Region: argRegion, MaxRetries: aws.Int(10)}
    if *argProfile != "" {
        creds := credentials.NewSharedCredentials("", *argProfile)
        config.Credentials = creds
    }
    sess := session.New(&config)
    svc := s3.New(sess)

    params := &s3.ListObjectsV2Input{Bucket: argBucket, Prefix: argPrefix}
    jst, _ := time.LoadLocation("Asia/Tokyo")
    svc.ListObjectsV2Pages(params,
        func(page *s3.ListObjectsV2Output, lastPage bool) bool {
            for _, obj := range page.Contents {
                fmt.Printf("%s %10d %s\n", obj.LastModified.In(jst).Format("2006-01-02 15:04:05"), *obj.Size, *obj.Key)
            }
            return *page.IsTruncated
        })

}

実行方法

# コンパイル
go build -o s3lsall main.go
# 実行
./s3lsall -profile {profile} -bucket {bucket} -prefix {prefix}

結果表示は、awscli(aws s3 ls)と同じフォーマットで出力されます

例
2019-01-22 11:46:39       8023 hoge/197352643.json
2019-01-23 11:16:28       5000 hoge/197512582.json
2019-01-23 19:46:02       4995 hoge/197512839.json

性能比較（参考）

t3.smallインスタンスで実行し、10万オブジェクトの一覧取得で比較

使用ツール 所要時間 CPU使用率
awscli 65秒 30%
s3lsall(go実装) 15秒 10%

まとめ

awscliで時間がかかりそうな大量リソースに対する処理などは、必要な処理に特化した
プログラムをGoでサクッと実装するとよさそうですね（速度／負荷的にも）

Go以外の言語でsdkを使ってプログラムを書いてもいいですが、そのランタイム環境を用意
しないといけないので、ワンバイナリ配布で実行できる、というのもGoのいいところですね！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-10T14:19:39+09:00

agoutiで撮ったスクリーンショットをzipする【Go】

概要

agouti + phantomjsでスクリーンショットを撮ったのち、ローカルに保存、zipにまとめる
zipはarchive/zipパッケージを使う

やり方

filename := "/path/to/file/screenshot.jpg"
page.Screenshot(filename)

dest, err := os.Create("screenshot.zip") //zip完成
if err != nil {
    log.Fatal(err)
}

zipWriter := zip.NewWriter(dest)
defer zipWriter.Close()

file, err := os.Open(filename)
if err != nil {
    log.Fatal(err)
}
defer file.Close()

w, err := zipWriter.Create(filename)//zip内にできるファイルのwriterを返す
if err != nil {
    log.Fatal(err)
}

_, err = io.Copy(w, file)//fileの内容をfilenameに書き込む
if err != nil {
    log.Fatal(err)
}

何か間違いがあればご指摘ください

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-10T07:54:14+09:00

DockerHubで公開されているコンテナが安全か確かめてみた結果【人気のコンテナ上位800個】

はじめに

Docker Hubに公開されているイメージはどの程度安全なのか、 Dockle stars と Trivy stars を利用して検証しました。
検証結果は、 https://containers.goodwith.tech/ に公開しています。

screencast24.gif

結論

基本的にどのコンテナにも脆弱性はある！
人気が高いコンテナ/最近ビルドされているコンテナでも関係ない！

ただ、Docker公式が用意しているコンテナは今のところ大丈夫。
より詳しいことを知りたい人は 操作方法 を見て、 https://containers.goodwith.tech/ を操作してみてください。

操作方法

page.png

① ソートやフィルタが簡単にできます

header-2.png

※ Scoreは脆弱性のCVSSスコアなどを元にした参考値です。指標を一つに統一したかったので作りました。
ガチ勢の方々、怒らないでください & よりよい指標をつくるためのアドバイスをください。

② Dockle, Trivy というカラムを選択すると、JSON形式で詳細な情報が表示されます

clickable-2.png

③ JSONのロードが遅いときは｢JSON Detail｣のリンクからダウンロードできます

jsondetail-2.png

※ netlifyを利用してるんですが、特に大きいJSONファイルの取得が遅いので、解決方法を知りたいです

何がチェックできるの?

CISベンチマークに沿っているかチェックできます。CIS(The Center for Internet Security)のセキュリティ専門家たちが発行している資料です。

slide17

簡単に言うと、Dockleの列ではイメージの設計が正しくされているか、Trivyの列では脆弱性のあるパッケージが使われていないかをチェックできます。

その他にも、パスワードが設定されていないユーザのチェックなど、Linuxの基礎的なセキュリティもチェックします。
original-checkpoint-comparison.png

ただし、すべてのコンテナで警告が出てしまうので、｢latestタグはやめよう｣｢Content Trustを有効にしよう｣の2項目は無視しています。

データの作り方

過去に記事にした Dockle stars と Trivy stars を利用しています。
対象のコンテナイメージに対してそれぞれスキャンしていき、結果を集計しました。なお800個のコンテナを平行処理して1時間掛かりませんでした。

なお、私はDockleの作者で、Trivyのメインコミッタの一人です。GitHub Starが増えると喜びます。

フロントエンドやホスト環境は?

reactnetlify.png

メインで使っているライブラリは以下のものです。
Docker Meetup Tokyo #31のLTに間に合わせるべく、画面のベース作成1日というギリギリのスケジュールだったためCreate React Appを利用しました。

├── public : JSONや画像など
├── src : ソースコード
└── yarn.lock

フォルダ構成は現在このようになっており、すべてnetlifyでホストされています。
ただ、ファイルサイズが大きくなるとnetlifyだと極端に遅くなります。
特に脆弱性の数が多いJSONデータのロードで顕著です。解決策があれば教えてください。

脆弱性対策はどうすればいい?

ここや、この記事の後半でお伝えしたとおり、どのように向き合うかは、そのサービスの用途や求めるレベルによります。

ただ、Trivyで検出された脆弱性については、新しいOSにして新しいバージョンのパッケージを入れたら脆弱性は減るので、公開されているDockerfileを元に自らの手で書き直すことをおすすめします。

脆弱性についてより詳しいことが気になった人は、私も参加しているプロジェクト Vulsのチームが主催する ｢既知の脆弱性はこう捌け！｣系の勉強会に参加すると、体系的に学ぶ事ができます。

最後に

最初に、Docker公式が用意しているイメージが今のところ大丈夫と伝えました。
しかし、いつ脆弱性が入るのかはわからないので、ビルドごとにイメージのチェックすることをおすすめします。実例として、今年の5月まで公式が用意したAlpine LinuxのイメージにRootユーザのパスワードが設定されていないという脆弱性がありました。

ローカルビルドの際に、すでにあるイメージを毎回参照していて、過去の脆弱性をそのまま使い続けている状況もありえます。ローカルでイメージを作成している人/コンテナのイメージをキャッシュから作成されている方は、特に一度スキャンすることをおすすめします。

なお、今後も https://containers.goodwith.tech/ に、ユーザーの入力したイメージ名からスキャンをするなど、機能追加していく予定です。 フッターにシェアボタン付けたので、シェアお願いします?

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-10T07:54:14+09:00

DockerHubで公開されているコンテナが安全か確かめてみた【人気のコンテナ上位800個！】

はじめに

Docker Hubに公開されているイメージはどの程度安全なのか、 Dockle stars と Trivy stars を利用して検証しました。
検証結果は、 https://containers.goodwith.tech/ に公開しています。

page.png

結論

基本的にどのコンテナにも脆弱性はある！
人気が高いコンテナ/最近ビルドされているコンテナでも関係ない！

ただ、Docker公式が用意しているコンテナは今のところ大丈夫。
より詳しいことを知りたい人は 操作方法 を見て、 https://containers.goodwith.tech/ を操作してみてください。

操作方法

① ソートやフィルタが簡単にできます

header-2.png

※ Scoreは脆弱性のCVSSスコアなどを元にした参考値です。指標を一つに統一したかったので作りました。
ガチ勢の方々、怒らないでください & よりよい指標をつくるためのアドバイスをください。

② Dockle, Trivy というカラムを選択すると、JSON形式で詳細な情報が表示されます

clickable-2.png

③ JSONのロードが遅いときは｢JSON Detail｣のリンクからダウンロードできます

jsondetail-2.png

※ netlifyを利用してるんですが、特に大きいJSONファイルの取得が遅いので、解決方法を知りたいです

何がチェックできるの?

CISベンチマークに沿っているかチェックできます。CIS(The Center for Internet Security)のセキュリティ専門家たちが発行している資料です。

slide17

簡単に言うと、Dockleの列ではイメージの設計が正しくされているか、Trivyの列では脆弱性のあるパッケージが使われていないかをチェックできます。

その他にも、パスワードが設定されていないユーザのチェックなど、Linuxの基礎的なセキュリティもチェックします。
original-checkpoint-comparison.png

ただし、すべてのコンテナで警告が出てしまうので、｢latestタグはやめよう｣｢Content Trustを有効にしよう｣の2項目は無視しています。

データの作り方

過去に記事にした Dockle stars と Trivy stars を利用しています。
対象のコンテナイメージに対してそれぞれスキャンしていき、結果を集計しました。なお800個のコンテナを平行処理して1時間掛かりませんでした。

なお、私はDockleの作者で、Trivyのメインコミッタの一人です。GitHub Starが増えると喜びます。

フロントエンドやホスト環境は?

reactnetlify.png

メインで使っているライブラリは以下のものです。
Docker Meetup Tokyo #31のLTに間に合わせるべく、画面のベース作成1日というギリギリのスケジュールだったためCreate React Appを利用しました。

├── public : JSONや画像など
├── src : ソースコード
└── yarn.lock

フォルダ構成は現在このようになっており、すべてnetlifyでホストされています。
ただ、ファイルサイズが大きくなるとnetlifyだと極端に遅くなります。
特に脆弱性の数が多いJSONデータのロードで顕著です。解決策があれば教えてください。

脆弱性対策はどうすればいい?

ここや、この記事の後半でお伝えしたとおり、どのように向き合うかは、そのサービスの用途や求めるレベルによります。

ただ、Trivyで検出された脆弱性については、新しいOSにして新しいバージョンのパッケージを入れたら脆弱性は減るので、公開されているDockerfileを元に自らの手で書き直すことをおすすめします。

脆弱性についてより詳しいことが気になった人は、私も参加しているプロジェクト Vulsのチームが主催する ｢既知の脆弱性はこう捌け！｣系の勉強会に参加すると、体系的に学ぶ事ができます。

最後に

最初に、Docker公式が用意しているイメージが今のところ大丈夫と伝えました。
しかし、いつ脆弱性が入るのかはわからないので、ビルドごとにイメージのチェックすることをおすすめします。実例として、今年の5月まで公式が用意したAlpine LinuxのイメージにRootユーザのパスワードが設定されていないという脆弱性がありました。

ローカルビルドの際に、すでにあるイメージを毎回参照していて、過去の脆弱性をそのまま使い続けている状況もありえます。ローカルでイメージを作成している人/コンテナのイメージをキャッシュから作成されている方は、特に一度スキャンすることをおすすめします。

なお、今後も https://containers.goodwith.tech/ に、ユーザーの入力したイメージ名からスキャンをするなど、機能追加していく予定です。 フッターにシェアボタン付けたので、シェアお願いします?

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-10T07:54:14+09:00

DockerHubで公開されているコンテナが安全か確かめてみた結果【人気のコンテナ上位800個！】

はじめに

Docker Hubに公開されているイメージはどの程度安全なのか、 Dockle stars と Trivy stars を利用して検証しました。
検証結果は、 https://containers.goodwith.tech/ に公開しています。

screencast24.gif

結論

基本的にどのコンテナにも脆弱性はある！
人気が高いコンテナ/最近ビルドされているコンテナでも関係ない！

ただ、Docker公式が用意しているコンテナは今のところ大丈夫。
より詳しいことを知りたい人は 操作方法 を見て、 https://containers.goodwith.tech/ を操作してみてください。

操作方法

page.png

① ソートやフィルタが簡単にできます

header-2.png

※ Scoreは脆弱性のCVSSスコアなどを元にした参考値です。指標を一つに統一したかったので作りました。
ガチ勢の方々、怒らないでください & よりよい指標をつくるためのアドバイスをください。

② Dockle, Trivy というカラムを選択すると、JSON形式で詳細な情報が表示されます

clickable-2.png

③ JSONのロードが遅いときは｢JSON Detail｣のリンクからダウンロードできます

jsondetail-2.png

※ netlifyを利用してるんですが、特に大きいJSONファイルの取得が遅いので、解決方法を知りたいです

何がチェックできるの?

CISベンチマークに沿っているかチェックできます。CIS(The Center for Internet Security)のセキュリティ専門家たちが発行している資料です。

slide17

簡単に言うと、Dockleの列ではイメージの設計が正しくされているか、Trivyの列では脆弱性のあるパッケージが使われていないかをチェックできます。

その他にも、パスワードが設定されていないユーザのチェックなど、Linuxの基礎的なセキュリティもチェックします。
original-checkpoint-comparison.png

ただし、すべてのコンテナで警告が出てしまうので、｢latestタグはやめよう｣｢Content Trustを有効にしよう｣の2項目は無視しています。

データの作り方

過去に記事にした Dockle stars と Trivy stars を利用しています。
対象のコンテナイメージに対してそれぞれスキャンしていき、結果を集計しました。なお800個のコンテナを平行処理して1時間掛かりませんでした。

なお、私はDockleの作者で、Trivyのメインコミッタの一人です。GitHub Starが増えると喜びます。

フロントエンドやホスト環境は?

reactnetlify.png

メインで使っているライブラリは以下のものです。
Docker Meetup Tokyo #31のLTに間に合わせるべく、画面のベース作成1日というギリギリのスケジュールだったためCreate React Appを利用しました。

├── public : JSONや画像など
├── src : ソースコード
└── yarn.lock

フォルダ構成は現在このようになっており、すべてnetlifyでホストされています。
ただ、ファイルサイズが大きくなるとnetlifyだと極端に遅くなります。
特に脆弱性の数が多いJSONデータのロードで顕著です。解決策があれば教えてください。

脆弱性対策はどうすればいい?

ここや、この記事の後半でお伝えしたとおり、どのように向き合うかは、そのサービスの用途や求めるレベルによります。

ただ、Trivyで検出された脆弱性については、新しいOSにして新しいバージョンのパッケージを入れたら脆弱性は減るので、公開されているDockerfileを元に自らの手で書き直すことをおすすめします。

脆弱性についてより詳しいことが気になった人は、私も参加しているプロジェクト Vulsのチームが主催する ｢既知の脆弱性はこう捌け！｣系の勉強会に参加すると、体系的に学ぶ事ができます。

最後に

最初に、Docker公式が用意しているイメージが今のところ大丈夫と伝えました。
しかし、いつ脆弱性が入るのかはわからないので、ビルドごとにイメージのチェックすることをおすすめします。実例として、今年の5月まで公式が用意したAlpine LinuxのイメージにRootユーザのパスワードが設定されていないという脆弱性がありました。

ローカルビルドの際に、すでにあるイメージを毎回参照していて、過去の脆弱性をそのまま使い続けている状況もありえます。ローカルでイメージを作成している人/コンテナのイメージをキャッシュから作成されている方は、特に一度スキャンすることをおすすめします。

なお、今後も https://containers.goodwith.tech/ に、ユーザーの入力したイメージ名からスキャンをするなど、機能追加していく予定です。 フッターにシェアボタン付けたので、シェアお願いします?

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧