サーバ起動時に任意のスクリプトを実行する(dockerコンテナを起動する) - Qiita
# !/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. touch /var/lock/subsys/local # 任意のコマンドを追加 sh /home/developer/sh/startup.sh ※この際に CentOS 7 などのsystemd系を使用しているOSであれば /etc/rc.local に実行権限が必要なようです。 背景 開発環境のコスト削減のため使用していないであろう深夜帯の時間は開発環境のサーバを stop するようになった。 その際に必要
「ソースコードで体感するネットワークの仕組みの開発環境をDockerで構築する - Qiita
ソースコードで体感するネットワークの仕組みの開発環境をDockerを使って構築します。著者はVirtual Machine上CentOS7.0を使い開発していますが、個人的にVirtualBoxに苦手意識を持っているためDockerを用いて開発環境を構築しました。対象としている読者は以下のとおりです。 Dockerに少しなれている イメージ、コンテイナーなどの用語がわかる 以下のコマンドが何をしているかがわかる docker pull docker run docker ps docker start docker attach ソースコードで体感するネットワークの仕組みを勉強したいがVirtualBoxを使いたくない 私自身、Dockerの勉強中です。もし用語や表現が間違えていたらコメントで指摘したいただければ幸いです。 開発環境構築 開発環境イメージをプル CentOS 7.0のイメー
DockerでGrowiをセットアップする - Qiita
概要 前から気になってるGrowiですが、docker-composeだと数行のコマンドでインストールが可能です。でも何となく使いたくないというか、詳しくない人間にとって、どこにデータが保存されているのかわからないものを使うのはやはり抵抗がありました。特にdockerはコンテナ削除すると中にあるデータも当然消えてしまうわけで、そんなものにいろいろ書き込むのは危険ですよね。 データを外に保存して、復元もできる方法をメモします。 mongodump等を使う方法もありますが、専用コンテナでそれほど規模も大きくない場合は丸ごとコピーで問題ないと思います。 環境 Ubuntu 18.04 ローカルで使用する (VirtualBox上で確認しました) 手順 ディレクトリは以下にしています。 作業ディレクトリ：/home/ubuntu データの保存先 ：/home/ubuntu/data 公式手順通りダ
Amazon EKS で Kubernetes を使う - Qiita
これは Getting Started with Amazon EKS の通りに作業した記録です。 世の中に沢山ある正式チュートリアルどおりにただなぞるだけの記事に存在意義はあるのか ??? と思っていたが自分でも書きます。書いてある通りに作業するのは難しい。四回くらい間違えました。そういう時意外と他人の記事で気付かされた点がありました。 この記録が英語版を参照しているのは、最初あまりにも上手く行かなくてに日本語版が間違っているのでは? と疑った名残です。多分日本語版でも大丈夫です。 作業の概要 準備: IAM Role や EC2 key pair を作る kubectl と heptio-authenticator-aws のインストール。aws コマンドの設定 CloudFormation で VPC を作る。VPC の情報はクラスタとワーカーノードの作成に使う。 aws eks c
CronJob をその場で Job を作って実行する方法 - Qiita
CronJob を書いた時に、一回実行したいときや、また CronJob で失敗したときなどで、もう一回実行したい時がたまにある。 その時に、わざわざ kind: Job を作らずに、 Cronjob を指定して Job を作成することができる。 kubectl create job -h $ kubectl create job -h Create a job with the specified name. Examples: # Create a job from a CronJob named "a-cronjob" kubectl create job test-job --from=cronjob/a-cronjob Options: --allow-missing-template-keys=true: If true, ignore any errors in templa
Envoy externals and ideas @builderscon2018の資料と関連リンクと補足 - Qiita
builderscon 2018で"Envoy externals and ideas" というタイトルで登壇します(した)。 発表資料内でのリンクや、ちょっとした補足をまとめました。 発表資料 関連リンク Envoy (Envoy proxy)、Istio とは？ (page 3) https://qiita.com/seikoudoku2000/items/9d54f910d6f05cbd556d 迷ったら健全な方 (page 11) https://www.publickey1.jp/blog/13/devopsdevops_day_tokyo_2013_2.html 生でプレゼンを見て凄く感動して、この記事も何度も読み返した覚えがあります。"いい感じ"というのを発表資料の1つのキーワードにしていましたが、実はここで書かれている"健全"という言葉でも置き換えられそう、、な位に影響を受
Kubernetes でデータ保存 - Qiita
Kubernetes でデータを保存する仕組みが難しかったのでまとめました。Kubernetes では、ロードバランサーの背後にコンテナを複数立ち上げて、一つのコンテナが落ちても勝手に復旧する一人データセンターみたいな事が簡単に手元の開発機で実現出来ます。コンテナの入れ物である Pod は使い捨てなので、データをとっておく事が出来ません。データを保存するにはちょっと工夫が必要です。 また、ストレージの機構は本番サーバで利用するサービスによってもまちまちなので、アプリから見てストレージの詳細を隠蔽するような仕組みも必要です。とりあえずサンプルコードです。 # sticky.yaml apiVersion: v1 kind: Service metadata: name: sticky labels: app: sticky spec: type: LoadBalancer ports: -
kubernetesのServiceとIngressをカンチガイしていた話 - Qiita
やりたかったこと アプリ開発中、バックエンドで使用する2種類のAPIサーバをkubernetesにデプロイし、Ingress経由で公開しようとしました。 そのときのエンドポイントを下のように設定しようとしました。 /server1 → APIサーバ１にアクセス /server2 → APIサーバ２にアクセス 使用しているkubernetes環境は以下の通りです。 ホスティングサービス: IBM Cloud Kubernetes Service バージョン: 1.9.10_1523 (ちょい古め) 起きたこと どちらのエンドポイントにアクセスしても、両方のサーバに均等に到達してしまう… 例： /server1 に３回アクセス → APIサーバ１に１回、APIサーバ２に２回到達 やらかした原因 例えば次のようなアプリをデプロイしていたとします。 name port binding
Docker コンテナで Embulk を動かす - Qiita
FROM openjdk:8-jre-alpine # Embulk 本体をインストールする RUN wget -q https://dl.embulk.org/embulk-latest.jar -O /bin/embulk \ && chmod +x /bin/embulk # 使いたいプラグインを入れる RUN apk add --no-cache libc6-compat \ && embulk gem install embulk-output-td WORKDIR /work ENTRYPOINT ["java", "-jar", "/bin/embulk"] 躓いたポイントが2点。 FROM openjdk:8-jre-alpine だと embulk gem install で失敗する flock unsupported or native support failed t
dockerコンテナでcgroupを使ったときにホスト側はどこでその設定を見れるかめも - Qiita
たとえば、docker-compose.ymlでmem_limitを使ったらcgroupでメモリの最大使用量を設定してますが、それはホスト側ではどこで設定されてるかの確認です。確認に使った環境はfedora 28です。dockerはsystemdで起動してます。 こんな感じでapp1は15MB、app2は20MBとしてメモリの上限をセットします。 version: '2' services: app1: build: context: . dockerfile: Dockerfile cap_add: - IPC_LOCK mem_limit: 15m app2: build: context: . dockerfile: Dockerfile cap_add: - IPC_LOCK mem_limit: 20m
Docker GitLab(gitlab/gitlab-ce)のMattermostにGitLabアカウントでログインしたいのに上手くいかなかった話 - Qiita
事始め 元々はVM(VirtualBox + CentOS7.1)でGitLabを公開していたのですが、 VMの置き場が自分の管理下のマシンではなく扱いづらいのが我慢できなくなったため、 思い切って自身が使っているLinuxマシン上でDockerを利用してGitLabを建て直そうと言うことになりました。 その際、Mattermost先生にも今まで通り活躍していただこうと設定していたのですが、 GitLabアカウントでのログインが出来るようになるまでエラい時間がかかってしまいました。 ちなみに私はGitLabのバックアップはMattermostのバックアップも併せてやっていると思っていたので、 この記事を書いている時点ではまだMattermostの完全な移行は完了していません。 手順をそのままなぞってもMattermostは新品を使う羽目になりますので、 その点では全く参考になりません。 あ
jooby(kotlin)の環境構築,swagger,docker化まで - Qiita
こんばんは。フォートナイトやってたら台風の爆音がうるさくて敵の足音が聞こえず殺されたmorifujiです 2018/09/19 追記 gitlabに使ったコードを載せました。開発環境もdockerで構築できるようにしたので割と便利です。 概要 Kotlinを触りたいなあと思っていたのでその練習がてらにjoobyなるものを触りました。 IntelliJでの環境構築 RESTfulAPI実装/Swgger出力 DBつなぎ込み(MySQL) ビルド docker化 までやったので知見を共有します。ちなみに僕はGradleとjavaはSIer時代３ヶ月ほどだけやっていましたがほぼ忘れている状態です jooby 早くてスケーラブルなmicroフレームワーク ベンチマークそこそこ早い(https://www.techempower.com/benchmarks/ その他、Railsと比較しているこちら
serverless.ymlのちょっと便利な書き方 with serverless-offline on docker - Qiita
やりたかったこと serverless.ymlのprovider.environmentにはローカル環境とデプロイする環境で別の値を入れたい デプロイする環境では同yaml内で作成したリソースのID等をRef:して定義したい resourcesはcloudformationなのでRef:等が使えるのは知ってる provider.environmentとかでもRef:したいんだけどできるのかな？ ローカル環境ではコンテナの環境変数を参照して定義したい ローカルは serverless-offline on docker な環境 そこではリソースの作成は行われないので、コンテナの環境変数を読む必要があった 結果 Ref:できた customにて、作成したリソースの情報を取得している 全てを試してはいないが、同yaml内であればどこでも使えそうな感じ ただし、!Refといった記述はできないっぽい
helmのtillerセットアップと簡易動作確認 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事について 簡易検証の必要があり、手元のWindows端末に用意したk8s cluster環境（vagrant）にhelmのtillerをセットアップした手順を整理したものです。（Qiitaで記事を作成する練習もかねてます。） 前提 Helm v2.9.1 ※検証作業時には2.10はRC版のみだったため2.9.1を利用。 ※kubernetes cluster環境はインターネットに接続な構成。 参考文献 RBACが有効なGKEでHelmを使う https://www.sambaiz.net/article/160/ Helm Do
kustomizeでconfigMapを取り扱うときの注意 - Qiita
configMapGeneratorの動作を考える 現在、kustomizeでConfigMapを処理する方法は2つの方法があり kustomizeのconfigMapGeneratorが若干クセのある動作をするので 軽くまとめておく tl;dr 雑に 基本的にはconfigMapGeneratorを使おう configMapの編集するたびに確実にconfigmapを違う名前にしたいのだったら configMapGeneratorを書く configMapの更新で名前が変わったら困るなら configMapもresourcesに書く 前提 kustomization.yaml deployment.yaml configmap k8s manifestとしてはdeployment + configMapという最小構成を考える 2つの方法の違いを見ていく resources の中に書いてre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Laradockでプロジェクトごとに環境構築する - Qiita
Amazon EKS Platform Version 2の新機能を試した（うまく動かず） - Qiita
Dockerコンテナ上にあるDBにSSHトンネルで接続する - Qiita
Dockerfile作成〜コンテナに入るまでのコマンド（備忘録） - Qiita
Xdebug+VSCodeで再びハマったメモ。vagrant+virtualbox+ubuntu上のdocker上のphp+nginx - Qiita
