Streamlit、とても便利ですよね!小さなアプリとしても、データ可視化にしても。 連載を通して、Google Cloud 上で Streamlit を上手に動かす方法をご紹介します。 Cloud Run での Hello, world! (本記事) Firebase 認証との連携 BigQuery へのクエリ GitHub、GitLab、Cloud Build での CI/CD Streamlit?なぜ Google Cloud で? Streamlit は「データ分析スクリプトを、数分で "共有できる Web アプリ" に変える」というキャッチコピー通り、Python で書かれたロジックをそのまま、直感的に、フロントエンドの経験がない人でも数分で Web アプリケーションにしてしまえるようなとても優れたフレームワークです。 まずはぜひ、公式サイトのギャラリー の一例を見てみてください
There are two main example folders flask_react (runs three services on localhost:5601/5602/3000) sh launch_app.sh creates a simple api that loads the text from the documents folder (if any), also launches the react frontend the "/query" endpoint accepts requests that contain a "text" parameter, which is used to query the index the "/upload" endpoint is a POST endpoint that inserts an attached text
前書き アプリケーション開発において大変重要となるのがテストです。既存のアプリケーションに様々な変更が入る度に、既存の機能に新たなバグを潜めてないか確認するために、多くのエンジニアが苦汁を舐めた経験があることでしょう・・・。(そこでバグが見つかればいいが、忘れたころに発見すると・・・) そんな面倒なテストを自動化するために、最近はテストコード、あるいはテスト自動化が流行ってきていると思います。 ただし、オンプレミスでテストを行っていると、すぐにテスト用のDBなんて用意出来ないです。そのため、開発用で利用しているDBをそのまま使うパターンがままあると思います。 しかし、そうなると次に問題になるのがDBの状態です。様々な開発及びテストによってぐちゃぐちゃになったDB内部のデータを利用すると、その状態に応じて、結果は変わってきます。このような状態になってしまうと、本来確認したい観点を確認すること
こんにちは、主に検索周りを担当しているエンジニアの伊藤です。 この記事は Enigmo Advent Calendar 2020 の 17 日目の記事です。 みなさんは適切なDockerfileを書けていますか?とりあえずイメージのビルドが出来ればいいやとなっていませんか? 今回は自戒の意味も込めて、改めてDockefileのベストプラクティスについて触れつつ、 そもそもDockerfileを書かずにコンテナイメージをビルドする方法とコンテナセキュリティに関する内容についてまとめてみました。 Dockerfileのベストプラクティス イメージサイズは極力小さくしよう ビルドキャッシュを活用しよう Dockerfileに関する悩みどころ Dockerfileを書かないという選択肢 Buildpack Cloud Native Buildpacks CNBの仕組み デモ CNBのメリット セキ
※この投稿は米国時間 2020 年 10 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。 デベロッパーとしてはソースコードを使用しますが、本番環境システムではソースを実行せず、実行可能なものが必要となります。かなり以前から、ほとんどの企業は Java EE(別名 J2EE)を使用しており、本番環境にデプロイする実行可能な「もの」は「.jar」、「.war」、「.ear」ファイルでした。これらのファイルはコンパイルされた Java クラスから構成されており、JVM 上で実行される「コンテナ」の内部で実行されていました。使用しているクラスファイルが JVM およびコンテナと互換性がある限りアプリは機能し、管理は不要です。 JVM ではない Ruby、Python、NodeJS、Go などが構築で使用され始めるまで、これらはすべてまったく問題なく機能していました
Pythonでお仕事する前提で、現在のところで自分が最適と考えるチーム開発のための環境整備についてまとめてみました。今までももろもろ散発的に記事に書いたりしていたのですが、Poetryで環境を作ってみたのと、過去のもろもろの情報がまとまったものが個人的にも欲しかったのでまとめました。前提としては次の通りです。 パッケージ管理や開発環境整備でPoetryを使う 今時はコードフォーマッター、静的チェックは当たり前ですよね? コマンドでテスト実行、コードチェックとか実行とかができる(CI/CD等を考えて) VSCodeでもコマンドで実行しているのと同じコードチェックが可能(ここコンフリクトすると困る) デプロイはDockerイメージ コンテナのデプロイ環境でコンテナに割り当てられたCPU能力を比較的引き出せて、スケールさせたら線形にパフォーマンスアップできるようなasyncioを前提とした環境構
How do buildpacks work?Buildpacks are distributed and executed in OCI images called builders. Each builder can have one or more buildpacks. The builder of the Google Cloud buildpacks that we are releasing today is available gcr.io/buildpacks/builder. Builders have the ability to auto-detect the language of your source code. This is accomplished by a `bin/detect` executable in the buildpack. The de
みなさん機械学習系の環境構築はどうやってますか? 僕は最近は Docker を使った管理を行っています。 特に師匠も居なかったので、ぐぐったり人のイメージを見たり手探りで docker をつかいつかいしている中で、最初からやっとけばよかったなーということがいくつかあるのでメモとして残しておきます。 大きく2つです。 キャッシュは消す テストを書く キャッシュは消す ライブラリをいろいろと install すると大抵の場合ダウンロードしたファイルを保存されている場合が多いです。何かのタイミングで再びそのライブラリをインストールする際にはダウンロードしたファイルを使って、素早くインストールすることができます (この仕組みがキャッシュです)。 キャッシュがあると容量が重くなるという欠点があります。重たいイメージは pull に単に時間がかかりますから、システムとしてデプロイする時にトラフィックが
English version 要約 dockerはデフォルトでセキュリティ機構(Spectre脆弱性の対策)を有効にします。この影響で、RubyやPythonのようなインタプリタは速度が劣化します。特にCPU律速なプログラムで顕著に遅くなります(実行時間が倍くらいになることがあります)。 現象 Rubyで1億回ループするコードを、直接ホスト上で実行する場合と、docker上で実行する場合で実行時間を比較してみます。 直接ホスト上で実行した場合: $ ruby -ve 't = Time.now; i=0;while i<100_000_000;i+=1;end; puts "#{ Time.now - t } sec"' ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] 1.321703922 sec docker
BusterとかStretchという名前が見慣れない方もいるかもしれませんが、これはLinuxディストリビューションとしてシェアの大きなDebianのコードネームです。 Debianバージョンが少し古いStretchの方がちょびっとサイズが小さかったりはしますが、まあ実用的にはサポートが長い方がいいですよね。slimを使ってGCCとかのコンパイラを自前でダウンロードしている記事とかもたまに見かける気がしますが、マルチステージビルドであれば、そんなにケチケチしなくていいのと、パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 Py
Numpy/Pandas、scikit-learnを使うPython実行環境を整えようとしているあなたへ。 悪いことは言わないので、alpineイメージを使うのはやめた方が良いです。 結論から slimイメージを使いましょう。 3.7系の最新であるバージョン3.7.5のベースイメージサイズの違いは以下の通り。 $ docker images python 3.7.5-alpine3.10 b11d2a09763f 8 days ago 98.8MB python 3.7.5-slim 46cf279fff55 11 days ago 179MB python 3.7.5 023b89039ba4 11 days ago 918MB あれこれパッケージ追加するのにAlpineは不向き Pythonでコンテナ環境を立ち上げるみなさんは多分 Numpyやscikit-learnを使いたい場面が多
Introduction to Dockerizing for Production Improve your DevOps skills: learn an iterative process for Dockerizing your code. Get your free ebook Faster Docker builds with pipenv, poetry, or pip-tools by Itamar Turner-Trauring Last updated 21 Mar 2023, originally created 17 Jun 2019 Docker builds can be slow, and waiting for a build to finish is probably not how you want to spend your time. So you
久々に開発ネタです. 大晦日ハッカソン2019 #大晦日ハッカソンで, 野球のデータをシュッと見るためのDashboardを作る(理由は後ほど). そんなDashboardのBackend APIをシュッと開発する. を目標に立て現在進行系でやってるのですが, 午後の進捗その2 Docker化が特に滞りなく完了. API Docも見れるとかFast API強すぎぃ 昨日の夕方から開発してたAPIはアッサリ1st Ver.できたので, 大晦日の買い物終わったらフロントエンドを除夜の鐘が鳴るまでになんとかするぞ #大晦日ハッカソン pic.twitter.com/wWMiSvQDKu— Shinichi Nakagawa (@shinyorke) 2019年12月31日 Backendを昨日(12/30)の18:00から着手して(実質作業時間)約5時間ちょいで完成させてしまいました. 本年最後
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く