雰囲気でDocker Composeを触っている状態から脱するために調べたこと（2023） - Activ8 Tech Blog
エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する
業務で使えるかもしれない…！？GitHub Actions の Tips 集 / CI/CD Test Night #7
https://testnight.connpass.com/event/311263/
GitHubのMerge Queueとは何か？それと、認識しておきたいこと - Mitsuyuki.Shiiba
同僚に「GitHubのMerge Queueってあんまり知らないんだけど、どう思う？」って聞かれて「あー。僕もあれよく分かってないんだよね」って返事をして、ちょうどいい機会なので見てみた 見てみた感想としては、いくつか気をつけておきたい点があるけど、チームの開発の進め方にうまくはまれば便利な機能だな、という感じ（なんでもそうか・・・） Merge Queueって? 2023年の7月にGAになったGitHubの機能 プルリクエストをマージするときに「マージ先のブランチ（ベースブランチ）の最新の変更を取り込んでからChecks（つまりCI）を実行して、それが成功したらマージしといて！」ってお願いできる便利機能。名前のとおりQueueになっているので複数のプルリクエストからenqueueできて前から順番に処理してくれる そうは言われても最初に説明を見た僕は「？？？」状態だった。「なんでこんな機能
Pkl :: Pkl Docs
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>name</key> <string>Swallow</string> <key>job</key> <dict> <key>title</key> <string>Sr. Nest Maker</string> <key>company</key> <string>Nests R Us</string> <key>yearsOfExperience</key> <integer>2</integer> </dict> </dict> </pl
組織でのはてなブログ運営をGitHub上で行うためのテンプレートリポジトリ「HatenaBlog Workflows Boilerplate」を公開しました - はてなブログ開発ブログ
GitHub上ではてなブログ運営を可能にするテンプレートリポジトリ「HatenaBlog Workflows Boilerplate」をベータ版として公開しました。 このテンプレートをご利用いただくと、組織でのブログ運営に求められるワークフロー(下書きの作成、更新、内容のレビューや公開など)をGitHub上で行うことができます。組織利用向けに整備していますが、どなたでもご利用いただくことが可能です。 導入方法や詳しい利用方法については、上記のリポジトリのREADMEをご参照下さい。 特長など 下書きの作成時に、作成した下書きのみが含まれたプルリクエストを自動で作成します*1。コンフリクトを防ぎ、ワークフロー上の管理を容易にします GitHub Actions を利用して動作するためローカルでの環境構築が不要です。GitHub組み込みのVisual Studio Code (github.d
「YAMLの本来の使い方」を仕様から読み取ってみる | Wantedly Engineer Blog
YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために
JSONとBigInt
ちょっと前にblueskyで見かけた話題。もとは「GraphQLのスキーマではintが32ビットしかなくて、64ビット整数とかないのがイケてない」といった話だったかなと思う。直感的にはこれは「Javascriptではすべてが倍精度浮動小数点数だから64bit intがないから」ということになるが、よくよく調べてみるといろいろややこしい歴史的事情があるようだ。 たしかにJSにはもともとひとつのNumber型しかなく、いわゆるdouble型(倍精度浮動小数点)だけで数値を表現してきた。IEEE754の倍精度浮動小数点数は仮数部が52ビットあるので、実際には32ビット整数ていどであれば全て誤差なく表現できる。なので32ビット整数または倍精度浮動小数点数がどちらも使えるというふうに理解されてきた。 そうはいっても不便なので、現代のJSにはBigIntがある。ES2020で導入されたらしい。ただし普
yamlについて思うこと
yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じ
GitHub Actionsのmatrixを動的に生成してGoの最新安定バージョンでテストする | おそらくはそれさえも平凡な日々
Goのライブラリを提供している場合、Goの最新の安定バージョンでテストしたくなることがあるでしょう。具体的にはマイナーバージョンの直近2バージョン、今だと1.18と1.17です。GitHub Actions定義への記述は以下のようになるでしょう。 jobs: test: runs-on: ubuntu-latest strategy: matrix: go-version: ['1.17', '1.18'] steps: - uses: actions/setup-go@v3 with: go-version: ${{ matrix.go-version }} - run: go test ./... しかしこのようにベタに書いてしまうと、Goのバージョンが上がったときにチマチマ上げるのが地味にめんどくさい。なのでこれを動的に生成したい。 これは事前にGoの安定バージョン一覧を取得するjo
GitHub Actions 逆引きリファレンス
1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo
Docker Compose V2で変わったdocker-compose.ymlの書き方
概要 2021年の後半にDocker Compose V2がリリースされました Docker Compose V2はCompose Spec[1]に準拠しているため、docker-compose.ymlもその仕様に則った書き方ができるようになっています services: app1: image: awesome/webapp configs: - my_config secrets: - server-certificate app2: image: awesome/database extends: service: app1 configs: my_config: file: ./my_config.txt secrets: server-certificate: file: ./server.cert services: app1: configs: - source: my_co
手軽に負荷テストができるツール「Taurus」がスゴい
modules: jmeter: version: 5.4.1 # ここに書いてあるバージョンを勝手にダウンロードしてくれる properties: log_level.JMeter: WARN log_level.JMeter.threads: WARN system-properties: org.apache.commons.logging.simplelog.log.org.apache.http: WARN 既存ツールのラッパーとして動作 デフォルトでは内部的にJmeterが実行されますが、以下のようなツールで作成されたスクリプトを流用することが可能です。 JMeter Gatling Locust Selenium Vegeta つまり、さきほどはYAMLでシナリオが記述可能とは言いましたが、もちろん既存のスクリプトを流用できるってことです。 いままで作り上げてきたスクリプトや
Go製アプリケーションのコンテナ化にはkoを推したい - YAMAGUCHI::weblog
はじめに こんにちは、Google Cloudでオブザーバビリティを担当しているものです。Cloud Operations suiteをよろしくおねがいします。（宣伝終わり） この記事はGo Advent Calendar 2021 その1の22日目の記事です。昨日は @sago35tk さんの「ESP32 向けに TinyGo をセットアップする」でした。TinyGoのコアな情報を日本語で教えてくれるtakasagoさんには本当にいつも感謝しています。 さて、今日はGo製のアプリケーションをdockerlessでコンテナ化できるkoの紹介をします。koは本当にイチオシのツールで、みんなに使ってもらいたいのでぜひ使ってください。 github.com DockerによるGo製アプリのコンテナ化 まず最もポピュラーと思われるDockerを用いた場合のGo製アプリケーションのコンテナ化の方法に
「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など
GitHub Actionsの歴史（2021/12/1 更新） - cangoxina
# はじめに GitHub Changelog を元に、GitHub Actions がどのように更新されていったかを簡単にまとめました。 あまり深いところまでは書いてないので、気になった変更があったら各自調べてください（もっと色々書きたかったけど時間なかった）。 わりと雑に作ったので漏れや間違いがあったらコメントとか下さい。 2021/12/01 までの情報をもとにこの記事は書かれています。 この記事は GitHub Actions Advent Calendar 2021 の 1 日目の記事です 🎅🎂 目次 # はじめに # 歴史 ## 発表 〜 正式リリース（2018/10 〜 2019/11） ## 2020 ### 1Q + α ### 2Q ### 3Q ### 4Q ## 2021 ### 1Q ### 2Q ### 3Q ### 4Q ## 2022 ### 1Q #
[github actions] Reusable workflowsが実装されたのでざっとまとめ
追記 年末にこの記事の内容も含めてgithub actionsをどう再利用するか総まとめしたのでそちらも併せてどうぞ！↓↓↓ この記事について 2021/11/24についにgithub actionsにReusable workflowsが実装されました。 まずは簡単にドキュメントをさらいながらポイントをまとめていこうと思います。 そもそも何が嬉しいのか これまでのgithub actionsではworkflowからactionを呼ぶことは可能だったものの、workflowから別のworkflowを呼ぶことはできませんでした。 workflowがひとつだけの場合そう問題にはならないのですが、同じworkflowの記述を使い回したい場合にはこれが問題になっていました。 例えば下記のようなworkflowを複数のリポジトリで使う場合、actions/checkout@v2とactions/se
![[github actions] Reusable workflowsが実装されたのでざっとまとめ](https://cdn-ak-scissors.b.st-hatena.com/image/square/c25aa961962cebb0eedf758efaeafa7f67419db9/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--yeJ2s6DH--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255Bgithub%252520actions%25255D%252520Reusable%252520workflows%2525E3%252581%25258C%2525E5%2525AE%25259F%2525E8%2525A3%252585%2525E3%252581%252595%2525E3%252582%25258C%2525E3%252581%25259F%2525E3%252581%2525AE%2525E3%252581%2525A7%2525E3%252581%252596%2525E3%252581%2525A3%2525E3%252581%2525A8%2525E3%252581%2525BE%2525E3%252581%2525A8%2525E3%252582%252581%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3AJerome_1010%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2Q1MWM1YjRlYzkuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
GitHub Actionsの手動実行パラメータのUI改善について速報で解説する
11/10に突如素晴らしいアップデートが来たので、興奮冷めやらぬうちに公式よりちょっとだけ詳しい解説を書きます。 GitHub Actionsは素晴らしいCI/CDサービスであり、特にpush, pull-request, その他あらゆるGitHub上の行動をトリガーにしてワークフローを起動させる設定を簡単に書くことができます。しかし、手動でワークフローを起動させる機能の追加は他のトリガーに比べて後発でしたし、パラメータを入力するための機能やUIが少々貧弱と言わざるを得ないものでした。 一方、古より存在するJenkinsはpush, pull-requestなどの自動トリガーを設定するのは難易度が高かった[1]反面、手動でジョブを起動する機能やUIは充実していました。基本の自由テキスト以外に、プルダウンによる選択、booleanのチェックボックス、Jenkinsに登録したシークレットからの
Github Actions チートシート
概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 push時に実行 // feature/aaaで動く。 feature/aaa/bbbでは動かない on: push: branches: - feature/* // feature/aaa, feature/aaa/bbbで動く on: push: branches: - feature/** // なにかしらのtagがpushされたときに実行、branchのpushは無視 on: push: tags: [ '**' ] branches-ignore: [ '**' ] // 指定したpathの変更だけでは実行しない on: push: branches: - main paths-ignore: - '*.md' - 'docs/**' on: workflow_dispatch: inputs
A new public beta of GitHub Releases: How we’re improving the release experience
ProductA new public beta of GitHub Releases: How we’re improving the release experienceGitHub Releases has a new look and updated tools to make it easier for open source communities to create and share high-quality releases with auto-generated release notes. GitHub is where developers come to learn and celebrate what’s new in open source, and where maintainers share, collaborate and celebrate thei
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - alacritty/alacritty: A cross-platform, OpenGL terminal emulator.
