今日からはじめるDocker - コンテナー仮想化の必要性を理解して、まず開発環境に導入してみよう！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
今日からはじめるDocker - コンテナー仮想化の必要性を理解して、まず開発環境に導入してみよう！ Dockerは、コンテナー仮想化ツールです。本稿では、サーバーサイドのアーキテクチャの歴史からDockerが生まれた流れや背景を説明し、PCの開発環境で実際にインストールしてDockerの動作を体験します。 エンジニアの方であれば、「コンテナー」や「Docker」といったキーワードを耳にしたことがあるかと思います。自分が関わっているシステムの開発や運用に活用できるかどうか検討している方もいるでしょう。 この記事の前半では、コンテナーやDockerとはそもそもどういったものかを概観していきます。後半では、PC（WindowsやMac）を使ってローカルでDockerを試していきます。 コンテナーとDockerを歴史から知る 仮想化前はすべて手作業だった サーバー仮想化技術の採用 パブリッククラ
もう XAMPP / MAMP はいらない！
Vagrant で作る PHP 開発環境
7. エンジニアSさん (c) 2013 Masashi Shinbara @shin1x1 1162 <VirtualHost *:80> 1163 ServerName candycane.local 1164 DocumentRoot "/Users/shin/sandbox/demo/candycane/app/webroot" 1165 </VirtualHost> 1166 1167 <VirtualHost *:80> 1168 ServerName demo.local 1169 DocumentRoot "/Users/shin/sandbox/demo/20130601_phpcon" 1170 php_value vld.active 1 1171 </VirtualHost> 1172 1173 <VirtualHost *:80> 1174 ServerName
1. Perl環境の設定 : Practical Modern Perl (仮)
注：本稿はまだ書きかけです！書きかけです！まだ一般に知らしめようとする前にブクマされました！ｗ 間違いの指摘やコメント等は lestrrat @twitter にください！ Perl環境の設定方法はここ数年で大きく進化し、変わってきました。ここではアプリケーションのデプロイも見据えた、モダンなperl環境の整え方を紹介していきます。具体的にはperl本体や外部モジュールのインストール方法を解説したのち、Perlを使ったアプリケーションを管理・運用していく際に依存関係等はアプリケーション毎に管理できるようにしてグローバル環境に可能な限り干渉しない方法を紹介します。 目次 1.1 Perl本体のインストール 1.2 依存モジュールの管理・インストール 1.3 Cartonによるアプリケーションの実行環境の構築 tl;dr 本稿を読む前にポイントだけ知りたい！という方向けのまとめです： OSに同
Vagrant 入門 - Windows 上に Linux の仮想マシンを簡単に用意する - 僕は発展途上技術者
naoya さんによれば、「便利すぎて鼻血が出ました」という Vagrant を触ってみて、僕も Git を最初に触った以来の衝撃を受けました。 » Vagrant - naoyaのはてなダイアリー 開発者、それも gem で入れることから、Ruby を使う開発者の一部で話題になっているようなのですが、Vagrant はこれからプログラミングしようと思っている初心者や、開発環境を用意する必要があるデザイナーにこそ、強力なツールなんじゃないかと思っています。 Vagrant が便利に思えるひとつのケースとして、Windows の上に Linux の仮想マシンを用意する、というのが挙げられます。Web 業界にいると勘違いしてしまいそうになるのですが、世の中のほとんどの人は開発者も含めて Windows を使っているでしょう。そういう人が PHP や Ruby などを始めてみたいと思った時に、難
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
