DEV Community: Martin Pham

Fully type-safe integration between your Laravel backend and your frontend

Martin Pham — Tue, 12 Aug 2025 11:55:13 +0000

TLDR: If you've ever wanted fully type-safe integration between your Laravel backend and your frontend (whether that's API consumers or Inertia.js apps), the laravel-type-generator package might save you a ton of time. I just released this package that I've been working on for a while.

Why I Built It

I wanted a completely type-safe workflow between Laravel and the frontend — so backend changes wouldn't silently break my frontend.

The Idea

The concept is simple: use OpenAPI to describe your API documentation, then feed it to tools like Orval to automatically generate TypeScript clients and types.

I tried several existing packages, but none gave me the accuracy or automation I was looking for. So I decided to build my own.

What It Does

The laravel-type-generator package scans your Laravel routes, controllers, models, DTOs, and their properties, methods, docblocks, and PHP source code. It then automatically generates:

TypeScript types from your Laravel routes
OpenAPI specifications for API documentation
Swagger UI to visualize and interact with your OpenAPI spec
Inertia.js type generation
Accurate handling of pagination, collections, and complex return types

(More transformers are coming soon!)

Think of it as a bridge that keeps your Laravel backend and frontend perfectly synchronized with types.

Installation

composer require martinpham/laravel-type-generator

Publish the config:

php artisan vendor:publish --tag="type-generator"

Then run:

php artisan types:generate

Configuration

The package is flexible. In the config file, you can customize what gets generated and where it goes. Here's a practical example showing how to generate:

An OpenAPI specification JSON file for routes matching /_api/*
TypeScript types for Inertia.js routes and template variables, for controllers matching App\Http\Controllers\Web\*

'route_prefixes' => [
    'uri:_api' => [
        'output' => resource_path('api/openapi.json'),
        'class' => 'MartinPham\TypeGenerator\Writers\OpenAPI\OpenAPI',
        'options' => [
            'openapi' => '3.0.2',
            'title' => 'OpenAPI',
            'version' => '1.0.0'
        ]
    ],
    'controller:App\Http\Controllers\Web\\' => [
        'output' => resource_path('js/types/inertia-routes.ts'),
        'class' => 'MartinPham\TypeGenerator\Writers\Inertia\Inertia',
    ],
],

Example: How Your Controller Becomes Typed API Specs

Let's say you have a simple controller method like this:

class PlaygroundApiController extends Controller
{
    public function findUser(User $user): User
    {
        return $user;
    }
}

Here's what happens under the hood:

The package analyzes the findUser method's input parameter (User $user) and return type (User).
It automatically generates an OpenAPI operation for this route with $user as a parameter.
It creates a User schema for both request and response types.
Since your User model has relationships (like Address and Country), it recursively generates schemas for those related models too — so your OpenAPI spec and TypeScript types reflect the complete data structure.

This means your frontend gets fully typed models, including nested relationships, without any extra manual work!

Seamless Integration with Orval for Type-Safe API Clients & Inertia template

Once laravel-type-generator creates your OpenAPI spec, you can feed it directly into Orval to automatically generate TypeScript types and API clients.

Here's what Orval would produce from the generated spec:

export interface User {
  id?: number;
  name?: string;
  email?: string;
  role?: string;
  address?: Address;
}

export interface Address {
  id?: number;
  street?: string;
  country?: Country;
}

export interface Country {
  id?: number;
  name?: string;
  code?: string;
}

export const apiPlaygroundUsers = (
  user: string, 
  options?: AxiosRequestConfig
): Promise<AxiosResponse<User>> => {
  return axios.get(`/_api/playground/findUser/${user}`, options);
};

What this means for you:

Your frontend knows exactly what data to expect — including nested objects like Address and Country
Your API calls are fully typed, with correct parameter and response types
No more guesswork or brittle any types when consuming your Laravel backend APIs

This creates a tight feedback loop between your backend and frontend, boosting developer confidence and reducing bugs from mismatched data structures.

Inertia template

On Inertia side, you will receive exactly the types which were returned by the route

Full Support for Various Data Types

The laravel-type-generator isn't limited to just Eloquent models. It also supports:

Plain PHP classes
Laravel Data objects (like from Spatie's laravel-data package)
API Resources
Your own custom-defined docblocks

To give you more control over the generated OpenAPI spec, you can use special docblock annotations in your controller methods:

@id — Overrides the default operationId (otherwise it's derived from the route name)
@tag — Adds tags to group and organize your API operations
@throws — Specify errors that could be thrown during the call
Method descriptions are also captured in the OpenAPI document

This flexibility lets you define complex return types with complete accuracy. For example:

/**
 * @return Collection<int, User>
 */
public function allUsers(User $user): Collection
{
    return User::all();
}

/**
 *
 * @return array{
 *     requestedAt: DateTime | null,
 *     users: User[],
 *     cars: Collection<int, Car>,
 *     carsWithPagination: LengthAwarePaginator<int, Car>,
 *     nestedObject: array{
 *         evenDeeper: array{
 *             message: string
 *         }
 *     }
 * }
 */
public function manything(Address $address): array
{
    return [];
}

Here's what's happening:

The package reads the docblocks and uses PHP's native type hints to generate detailed, nested TypeScript types and OpenAPI schemas.

Collections, paginated results, arrays with nested objects — everything gets parsed and converted correctly.

This means you can describe even very complex API responses in your controller methods and get fully typed clients on the frontend without any manual synchronization.

Specifying Request Parameters

Your API request parameters can come from different places, and laravel-type-generator supports all of them to generate accurate types:

1. Route Path Parameters

Simply define parameters in your route URL, like /users/{user}/. These will be automatically detected and typed.

2. FormRequest Subclasses

You can define a FormRequest class with typed properties and validation rules. The package inspects both your docblock properties and validation rules to generate the parameter types.

Example:

/**
 * @property UploadedFile $file
 * @property string $nickname
 * @property array{
 *     name: string,
 *     age: int
 * } $person
 */
class GreetingRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'file' => ['file'],
        ];
    }
}

3. Docblock Annotations on Controller Methods

You can also specify request shapes directly in your controller method's docblocks using generics and param tags:

/**
 * Greet
 *
 * Generates a greeting message.
 *
 * @id greeting
 * @param Request<array{
 *     user_id: int
 * }> $request
 * @param string $name The receiver's nickname.
 * @return Message|null The greeting message
 * @throws InvalidName Invalid name provided
 * @throws \InvalidArgumentException Invalid args provided
 */
public function greeting(Request $request, $name): ?Message
{
    // ...
}

This tells the package exactly what your request parameters should look like, allowing for precise type generation.

Development & Feedback

This package is under very active development, and I’m constantly working to improve it.

I hope you find it useful! Feel free to try it out, and please suggest any features or improvements you’d like to see.

Your feedback helps make this tool better for everyone!

Building the perfect automated workflows for Blockchain's development

Martin Pham — Mon, 22 Nov 2021 13:36:10 +0000

Build workflow for Blockchain's development

TLDR: We were having a bad time with Blockchain smartcontract's development, and fortunately we had found solutions to save our asses. We'd like to share it with you, so maybe it could be useful to you also.

Welcome to the Blockchain
Problems with our development/deployment
Writing Upgradable smartcontracts
Automatic deployment to the blockchains
Problem with the Truffle's migration process
Our completed workflows

Blockchain is fun!

It's a huge public database (chain of data blocks), which is being shared across many computers. Everyone can query data inside it, or add a new record by sending transactions. Everything is stored historically, so you can trace the changes easily.
With ethereum chains, it's even funnier with SmartContract - a program that runs on chains. Developers can write and compile a program, and upload it into the chain. Then everyone can run it to read its data, update its data with transactions, or even use it to run another program.

Tips: You can use this tool Smartcontract UI to interact with smartcontracts easily.

We were working on many projects based on blockchains, mainly in decentralized finance. Many of them are programs (written with Solidity) that involve managing users' account balance, allowing users to trade their assets, or to stake their assets to the liquidity pools and gain interests.

Problems with our development/deployment

However, we were usually facing a big problem: Smartcontracts in ethereum chains are immutable. It means once you deployed it on the chain, there is no way to change it. It works just like a contract we have in real life: you surely won't change the contract's contents once you signed it, if you want to, you'd need to have another contract. Same in ethereum chains, if we make changes in the contract code, we'd need to deploy it again to a new smartcontract.

And since a smartcontract has its data, when we deployed to a new smartcontract, we'd need to migrate all data from the old contract to the new one, while keeping support on both contracts until all users moved to the new contract.

Another problem we were having is the contract's deployment. After finishing the code and passing all tests on the local environment, we rely on someone to deploy it to the test chains so we can test its communication with other contracts. And since the contract's address will be changed each deployment, it's a really big pain for us to update all the addresses on each deployment.

After the contract's deployment, we have another problem with the interaction with our contracts. We provide ABIs (Application Binary Interface) to other people, so they can use them to interact with our contracts. It's also needed for our team to write applications that interact with contracts, so we'll need to keep them always updated with our deployed contracts.

SmartContract's development is fun, but its deployment was a pain for us for a long time.

Writing Upgradable smartcontracts with OpenZeppelin

We've decided to improve our deployment process. Thanks to OpenZeppelin, we're now able to upgrade our contracts smoothly.
When we deploy the contract on the first time, OpenZeppelin will create a Proxy Contract, points it to our actual contract, and finally, it deploys all contracts. Later, every time we make changes to the contract's code, OpenZeppelin will deploy it, and points the Proxy Contract to the newly deployed contract, keeping the old contract's state. Now we don't have to worry about the migration between contract's deployments. Our users and devs always connect with the Proxy Contract address, which points to the latest deployed contract.
It was a good change, that helped us during the release process. However, we were still having other problems with the deployment: We'd still need someone to build the contracts and deploy them to the chains. It requires access to our deployer's wallet, and we cannot give the wallet access to everyone in the team.

Automatic deployment with Github Actions and Workflows

After many tries, we finally integrate our build & deployment process with Github workflows. We also added some tweaks (like caching dependencies for faster build in future, configuring Truffle environment correctly, having wallet's private key in Github's secret,..)
Our deployment is automatic now! Every time we merge features into a development branch, a workflow will be triggered to build the contracts and upload them into the test blockchain. And when they are ready for production, we just need to tag the version. Github will deploy the contracts into the production blockchain.
We also release the contract's built artifact to Github release page every time we release the contracts to production, along with the prerelease of the contract's ABI on each push to the development branches. In this way, our users and devs can always update the contract's ABI quickly and easily.

Memorize Truffle's migration process

Everything seems OK, but actually, we're still missing a piece: We use actions/cache@v2 to cache the Truffle's build. So in the next deployment, we can continue the migration without doing it from the beginning.
However, the cache will be removed after some inactivity time, and when it's removed, or if there is some problem in the cache (cause of a wrongly configured deployment), our migration process will be restarted from the beginning. Therefore, all the proxy contracts will be changed. We will need to notice our users and devs, and migrate all contract's state.
Again, we had to try other approaches, and finally, we found a solution: Saving the Truffle's build on a deployed branch. So for each deployment, instead of taking the previous build from the cache, we will pull it from the deployed branch, and continue with it. It has some more advantages:

The Truffle's build will be there always
We can inspect the Truffle's build if there was any problem with the deployment
We can also customize the deployed branch to give more informations

Submission Category: DIY Deployments

Yaml File or Link to Code

ActionsHackathon21 / deploy-upgradable-smartcontract-to-blockchain

Deploy upgradable smartcontracts to blockchain

Build documentations

This project follows the DEV.to #ActionsHackathon21 hackathon.

Use GitHub Actions and Workflows to build and deploy upgradable smartcontracts into the ethereum blockchains. After its deployment, the contract's ABI will be released, and the artifacts will be saved into a deployed branch.

Check the complete workflow here:

Deploy contracts to testnet on each push on development branches (migrate-to-testnet.yml)
Deploy contracts to mainnet on each push on tag (migrate-to-mainnet.yml)

Actions used

actions/checkout@v2 To checkout the source code from the repository
actions/cache@v2 To cache the dependencies, allow us to re use them for future builds
marvinpinto/action-automatic-releases@latest To release your build to Github Release page

Configurations

You can config the branch postfix which holds the development's artifacts with the DEPLOY_BRANCH_POSTFIX variable.
You can also configure the development branches which you want to deploy to testnet, with branches key.
To config the blockchain you want to deploy to, use…

View on GitHub

Configuration

You can config the branch postfix which holds the development's artifacts with the DEPLOY_BRANCH_POSTFIX variable.
You can also configure the development branches which you want to deploy to testnet, with branches key.
To config the blockchain you want to deploy to, use the WALLET_SECRET , RPC, NETWORK_ID and CONFIRMATIONS variables Important! You should store the wallet secret in GitHub's secret (Settings > Secrets). On this project, I stored as DEV_WALLET_SECRET and PROD_WALLET_SECRET secrets

Flows

Use actions/checkout@v2 to checkout source code from the repository
Use actions/setup-node@v2 to setup nodejs
Use actions/cache@v2 to cache dependencies
Install build dependencies (yarn, node-gyp, node-gyp-build)
Install dependencies from yarn.lock
Synchronize previous built artifacts from the deployment branch
Build and Migrate smartcontracts
Push new built artifacts into the deployment branch
Release smartcontracts' JSON (including ABI)

Automatic build and publish documentations on Github Pages

Martin Pham — Mon, 15 Nov 2021 18:33:23 +0000

Build documentations workflow

With any project you work on, especially an open source project, documentation should be one of the most important things to do. It helps the end-users understand how to use the application, it helps the new developers understand how to work with the project, ...

With MkDocs, we can maintenance the documents easily. Just write documentations in Markdown, and it will build it into HTML static pages for you. Beside it, with the help from GitHub workflows, we can also build the documentations automatically on every push into our GIT repository.

I'd like to share with you my workflow to build documentations. It will listen for changes on documentation files (*.md), then build it and publish it into Github Pages.

Submission Category: DIY Deployments

Yaml File or Link to Code

ActionsHackathon21 / build-documentations

Build documentations

This project follows the DEV.to #ActionsHackathon21 hackathon.

Use GitHub Actions and Workflows to build your documentations with MkDocs, then publish to Github Pages.

Check the complete workflow here (build-documentations.yml)

Actions used

actions/checkout@v2 To checkout the source code from the repository
actions/cache@v2 To cache the dependencies, allow us to re use them for future builds

Configurations

You can config the branch which holds the documentations with DOCUMENTATIONS_BRANCH variable.
You can also configure the branches which you want to run this workflow, with branches key.
To configure the Github pages, you can go to settings > pages > Source and choose the documentation branch.

Flows

Use actions/checkout@v2 to checkout source code from the repository
Use actions/cache@v2 to cache dependencies (.pip directory)
Install dependencies with pip
Build documentations with Mkdocs
Synchronize built files with deployment branch
Push build into the deployment branch

View on GitHub

Configuration

You can config the branch which holds the documentations with DOCUMENTATIONS_BRANCH variable.
You can also configure the branches which you want to run this workflow, with branches key.
To configure the Github pages, you can go to settings > pages > Source and choose the documentation branch.

Automatic release new version, and notify your followers about it, using Github workflows

Martin Pham — Sun, 14 Nov 2021 11:06:22 +0000

Automatic release new version on tag workflow

Managing an open source project really takes a lot of efforts. There are many repeated tasks which wastes your time everywhere: Testing, Building, Releasing, ... and sometimes, you'd also want to update your followers with the new released version.

Fortunately, Github actions & workflows came to rescue! With tons of available actions, we can automate many repeated & boring tasks, and keep our time to focus on code.

Today I'd like to share with you a GitHub worklow to build and release your application into a Github release, then notify your followers about this new release.

With this worklow, we automate all the testing, building steps and releasing steps, everytime you push a new release tag (example: v0.0.1, v0.0.2,...). Then send a new message about the newly released version to a Telegram channel.

Submission Category: DIY Deployments

Yaml File or Link to Code

ActionsHackathon21 / release-on-tag

Release a new version on very tag, then notify your followers on social networks

Release new version on tag

Bonus: Also notify your followers on every update!

This project follows the DEV.to #ActionsHackathon21 hackathon.

Use GitHub Actions and Workflows to build and release your application on every release tag.

Then send an announcement to your Telegram channel about the new release

Check the complete workflow here (release-on-tag.yml)

Actions used

actions/checkout@v2 To checkout the source code from the repository
actions/cache@v2 To cache the dependencies, allow us to re use them for future builds
marvinpinto/action-automatic-releases@latest To release your build to Github Release page

(Also actions/setup-node@v2 for setup nodejs, although it's not required)

Configurations

You can config the release tag prefix, with on.push.tags key.
To send announcement to Telegram, you need to configure the workflow using following steps
- Talk with Telegram's @BotFather to create a new bot if you don't have one. We will use this bot to send messages to the Telegram channel. He…

View on GitHub

In the repository, there is a sample NextJS project, however you can change a bit on the workflow file to match your project.

Configurations

You can config the release tag prefix, with on.push.tags key.
To send announcement to Telegram, you need to configure the workflow using following steps:
- Talk with Telegram's @BotFather to create a new bot if you don't have one. We will use this bot to send messages to the Telegram channel. He will give you the token access the HTTP API.
- On your Telegram channel, grant admin permissions to the bot.
- Set the TELEGRAM_CHANNEL variable.
- Add the TELEGRAM_BOT_TOKEN secret (using the token access above) into your repository secret (Settings > Secrets > New repository secret)

Pre-release

There is also a pre-release workflow (prerelease-on-push.yml), which will build and create a pre-release version of your application, on every push to main branch.

Automatic deployment to GIT branch with GitHub workflow

Martin Pham — Tue, 09 Nov 2021 13:55:26 +0000

Deploy application to GIT branch workflow

Sometimes, there are limitations which prevent your deployment flow from working properly. One of these limitations we were facing sometime, was the build and release process.

Usually, we store our code on a GitHub repository, then setup a webhook on it. So each time we push a new commit into the release branch, GitHub will trigger a webhook call to a script our server, which pulls the latest commit, builds the application, and releases the build.

It was a nice deployment flow, everything including pulling, testing, building, releasing,... worked automatically. However, after months, we've noticed a few issues with that:

When our server receives a webhook call, it has to test and build the projects. As the project continues growing bigger, the build process becomes slower. Everytime it builds, our server's resources (CPU, RAM, ...) spikes up, affects performances of other running applications.
It's hard to rollback to different deployments.
...

After discovering GitHub workflows, we've found a way to improve our deployment process, with many GitHub Actions. And today we'd like to share it with you: We've created a GitHub worklow to build and deploy our application into a Git branch.

With this worklow, we automate all the testing and building steps, then store the ready-to-run build into another branch. Our server just needs to pull the latest build from the deployment branch, and release it. And sometime, if we want to switch between versions, simply switch between commits. We can also trace the build files change back to the commit which made it.

Also, thanks to the actions/cache@v2 action, we could also reduce the building time by caching the dependencies. It allows us to re-use them for future builds

Bonus: You can also use it to deploy to Github Pages, by selecting the destination branch as the Github Pages's branch.

Submission Category: DIY Deployments

Yaml File or Link to Code

ActionsHackathon21 / deploy-to-git-branch

Use GitHub Actions and Workflows to build and deploy your applications to a branch. So you can just pull this branch to deploy on the production server, without building.

Deploy application to GIT branch

This project follows the DEV.to #ActionsHackathon21 hackathon.

Use GitHub Actions and Workflows to build and deploy your applications to a branch. So you can just pull this branch to deploy on the production server, without building. You can also use it to deploy to Github Pages, by selecting the destination branch as the Github Pages's branch.

Check the complete workflow here (build-and-deploy-to-branch.yml)

Actions used

actions/checkout@v2 To checkout the source code from the repository
actions/cache@v2 To cache the dependencies, allow us to re use them for future builds

(Also actions/setup-node@v2 for setup nodejs, although it's not required)

Configurations

You can config the deployment branch postfix, with DEPLOY_BRANCH_POSTFIX variable. So the code on "main" branch will be built and pushed into main-<DEPLOY_BRANCH_POSTFIX> branch
You can also configure the branches which you want to run this workflow, with branches key.

Flows

In this repository, I use…

View on GitHub

In the repository, there is a sample NextJS project, however you can change a bit on the workflow file to match your project.

Configuration

You can config the deployment branch postfix, with the DEPLOY_BRANCH_POSTFIX variable. Example: the code on main branch will be built and pushed into main-<DEPLOY_BRANCH_POSTFIX> branch
You can also configure the branches which you want to run this workflow, with branches key.

Coronavirus COVID-19 outbreak dashboard

Martin Pham — Thu, 19 Mar 2020 11:26:06 +0000

TLDR, I've built a Coronavirus COVID-19 dashboard here

COVID-19 outbreak is not a hoax anymore

I've seen people around calling it "just-another-flu". And to be honest, I was thinking the same, until 3 weeks ago, when Italy started to see growing COVID-19 clusters. And 2 weeks ago, Italy went full nation lockdown. Our life changed completely.

Lacking information

We've seen what happened in Wuhan, China, in Korea. But we never thought it would happen here.
We didn't know what to protect ourselves.
We lost in fake news, in fake articles (I saw some articles on Facebook, saying hand dryers can kill the viruses!)

That's why I've decided to build a COVID-19 dashboard

I want to update the current situation to everyone, in every country. So people can see what's happening with other countries, and understand that it will happen in their country as well.

I want to put trusted information from WHO and universities, experts. To help people protect themselves and their family.

Don't forget, our country is fully locked down, in just 3 weeks.
Thanks

Develop a Telegram chat bot to update Coronavirus COVID-19 situation

Martin Pham — Tue, 25 Feb 2020 10:22:15 +0000

TLDR

Try the bot here https://t.me/covid19liveupdate

Coronavirus COVID-19

As all you've already known, the novel coronavirus COVID-19 is affecting 37 countries and territories around the world and 1 international conveyance (the "Diamond Princess" cruise ship harbored in Yokohama, Japan). None of us want to panic, but informations are very helpful for every people.

How I created the bot?

With NodeJS and telegraf framework, it's pretty easy to create a Telegram bot for youself.

1) Create a bot

Before doing everything, you need to register a new bot with Telegram. Just need to chat with @BotFather, he will help you through steps (start with /newbot)

In the end, the @BotFather will register your bot, and give you an API Token. Write it down, we'll need it for next steps.

2) Write bot's logic

It's the heart of your new bot, it will listen for messages, commands from users, and replies them as you prepared.

Install telegraf

yarn add telegraf

Init the bot

# bot.js

const Telegraf = require('telegraf')

const BOT_TOKEN = '*** The API Token you got from previous step ***'

const bot = new Telegraf(BOT_TOKEN)
bot.start((context) => context.reply('Welcome!'))
bot.help((context) => context.reply('You can say hi'))
bot.hears('hi', (context) => context.reply('Hey there!'))
bot.launch()

There it is! Very simple right? Your bot will say "Welcome!" for new user, or says "You can hi" if user asks for help, and replies "Hey there!" if user says "hi"

How my bot can send message?

There are 2 cases which the bot can send a message:

Send message / Reply to a chat (bot <-> user)
Broadcast to a channel (admin -> users)

1) Send messages in a chat

To send a message in a chat, you need to know the current chat. You can take the chat's information in the context variable in the previous example.

When you're able to take the Chat ID from context.chat, you're ready to send a message:

Reply to current chat:

context.reply('*** Your message ***')

Send a message to current chat (without user's message):

bot.telegram.sendMessage('*** Chat ID ***', '*** Your message ***')

2) Broadcast messages to a channel

To boardcast a message in a chat, you need to add the bot into your channel and make it becomes an admin.

Then you can simply send messages using:

bot.telegram.sendMessage('@YourChannelName', '*** Your message ***')

That's all! In next tutorials, we'll work together to deploy our bots to cloud, and keep it running to handle user's requests.

Try PHP 8.0 beta features with Docker / Kubernetes

Martin Pham — Mon, 03 Feb 2020 10:47:13 +0000

PHP 8.0's development had started one year ago. With many promising features like: Union types, JIT, Static return type, Weak maps, ..., probably you'd like to give it a try. Or simply, you just want to know if your codebase will run fines with future PHP version. So I've created PHP 8.0 beta Docker images for you :)

The base image martinpham/php8:fpm-alpine contains PHP 8.0 FPM, built from PHP source code, and based on Alpine Linux, so it's quite small and fast. It also supports multiple architectures (linux/amd64, linux/arm64, linux/386, linux/arm/v7, linux/arm/v6), so you can run it even on a small Raspberry Pi!

Docker

You can try to run it now:

docker run -p 9000:9000 --rm martinpham/php8:fpm-alpine

Docker will pull the image, and creates a new container with this image, also exposes port 9000 for PHP-FPM server. (Note: The --rm option tells Docker to remove the container after it finishes).

If everything goes fine, you'd see logs from Docker:

NOTICE: fpm is running, pid 1
NOTICE: ready to handle connections

To make sure, you could also try to send request to the PHP-FPM server:

REQUEST_METHOD=GET cgi-fcgi -bind -connect localhost:9000

(Replace localhost with your Docker's Host IP)

PHP-FPM will respond:

X-Powered-By: PHP/8.0.0-dev
Content-type: text/html; charset=UTF-8

Everything is good! You are running your first PHP 8.0 beta - FPM server!

Kubernetes

If you were following my Kuberetes tutorial before, probably you'd like to deploy it on your Kubernetes cluster :).
Well it's very easy, here is a sample configuration, with:

A persistent volume (code-pvc) for storing application code
A config map (nginx-config) for nginx configuration
A deployment (app-deployment) with PHP 8 FPM server and NGINX web server
A service (app-service) to expose deployed pod (tagged with name: app-pod)

## App code volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: code-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

---

## Nginx config
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-config
data:
  nginx.conf: |
    events {
    }
    http {
      server {
        listen 80;
        listen [::]:80;

        root /var/www/html;
        index index.html index.htm index.php;

        location / {
          try_files $uri $uri/ =404;
        }

        location ~ \.php$ {
          include fastcgi_params;
          fastcgi_param REQUEST_METHOD $request_method;
          fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
          fastcgi_pass 127.0.0.1:9000;
        }
      }
    }

---

## App deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 1
  strategy:
    type: Recreate    
  selector:
    matchLabels:
      name: app-pod
  template:
    metadata:
      name: app-pod
      labels:
        name: app-pod
    spec:
      volumes:
        - name: app-files-volume
          persistentVolumeClaim:
            claimName: code-pvc

        - name: nginx-config-volume
          configMap:
            name: nginx-config

      containers:

        # php-fpm
        - name: phpfpm
          image: martinpham/php8:fpm-alpine
          volumeMounts:
            - name: app-files-volume
              mountPath: /var/www/html
          resources:
            limits:
              cpu: 100m
            requests:
              cpu: 50m

        # nginx
        - name: nginx
          image: nginx:alpine
          volumeMounts:
            - name: app-files-volume
              mountPath: /var/www/html
            - name: nginx-config-volume
              mountPath: /etc/nginx/nginx.conf
              subPath: nginx.conf
          resources:
            limits:
              cpu: 100m
            requests:
              cpu: 50m

          ports:
          - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 3
            successThreshold: 1

--------

## App service
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    name: app-pod
  ports:  
  - name: http
    port: 80
    targetPort: 80
    protocol: TCP

Additionally, I've also built an "extra" image, called martinpham/php8:fpm-extra-alpine, which extends from the base image, with mysqli, gd, pdo_mysql and opcache extensions, so you can start to try other extensions with PHP 8.0.

PS: All images above are open-sourced, you can find it here https://github.com/MartinPham/php8-docker

Symfony 5 development with Docker

Martin Pham — Mon, 30 Dec 2019 09:03:06 +0000

We were playing with Kubernetes last week, however the project was just a small PHP file with phpinfo() function call, no big deal.

Today my colleague asked me to guide him a bit on Docker, because he’d like to try it with a real world example: Developing a Symfony project. So let’s take a look at this, it's quick, easy and fun!

Symfony uses Composer to manage its dependencies and scripts, namespaces,.. with a file named composer.json. Dependencies will be download to a directory called vendor.

Focus on development, we'd like to create a ready configured & isolated environment, so anyone can clone the repository and run the application easily. So we’re gonna use 3 containers:

MySQL, with mounted volume for data persistent
PHP-FPM, with mounted volume for application’s code
NGINX, with mounted volumes for configurations, logs, and share mounted volume with PHP-FPM for application’s assets

We will also need to use some environment variables for containers’ parameters, like database credentials, application secret key,…

We’re gonna use Docker-Compose to put configurations and run all containers.

Project
│
├── docker-compose.yml
│
├── database/
│   ├── Dockerfile
│   └── data/
│
└── php-fpm/
│   └── Dockerfile
│
├── nginx/
│   ├── Dockerfile
│   └── nginx.conf
│
└── logs/
    └── nginx/

MySQL Database

Let’s just create a MariaDB container

# docker/database/Dockerfile

FROM mariadb:latest
CMD ["mysqld"]
EXPOSE 3306

Explaination

We use MariaDB official image
Run mysqld to start the server
Expose port 3306 for database connection

PHP-FPM

With PHP-FPM container, we’d like to install dependencies and run database migrations at start. So we need to install the PDO MySQL extension, then composer, and then Symfony migration script.

However, it could be a problem if we run the migration before the MySQL server is ready. We will need to handle this also.

With Docker-compose, we can specify a depends_on configuration to tell it wait for another container. But it doesn’t mean Docker-compose will wait until the MySQL server is ready, it only waits until the MySQL container is up.

Fortunately, with the help from wait-for-it script, we can try to wait until the MySQL container’s port 3306 is Open (Or you can even try to wait until you can connect to the MySQL using credentials).

# docker/php-fpm/Dockerfile

FROM php:fpm-alpine
COPY wait-for-it.sh /usr/bin/wait-for-it
RUN chmod +x /usr/bin/wait-for-it
RUN apk --update --no-cache add git
RUN docker-php-ext-install pdo_mysql
COPY --from=composer /usr/bin/composer /usr/bin/composer
WORKDIR /var/www
CMD composer install ; wait-for-it database:3306 -- bin/console doctrine:migrations:migrate ;  php-fpm 
EXPOSE 9000

Explaination

We use PHP-FPM offical image
Copy wait-for-it script into the container
Allow execution for wait-for-it
Add git for dependencies installation
Install PHP PDO MySQL
Take composer file from Composer official image
Set working dir to /var/www
Install dependencies, then wait until the MySQL container is Online to run migration script. Finally, run php-fpm to start the server
Expose PHP-FPM port (9000)

NGINX

Okey, this part is a bit complex, we’re gonna create the NGINX configuration file, the PHP-FPM proxy, and a separated file for default NGINX site.

First the Dockerfile definition

# docker/nginx/Dockerfile

FROM nginx:alpine
WORKDIR /var/www
CMD ["nginx"]
EXPOSE 80

Explaination

As above, we use NGINX official image
Set working dir to /var/www, the same directory with PHP-FPM since we’re gonna share this with a mounted volume
Start nginx
Expose the port 80 for web

Now, an NGINX server configuration

# docker/nginx/nginx.conf
user  nginx;
worker_processes  4;
daemon off;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    keepalive_timeout  65;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-available/*.conf;
}

An NGINX – PHP-FPM configuration

# docker/nginx/conf.d/default.conf

upstream php-upstream {
    server php-fpm:9000;
}

And an NGINX site’s configuration

# docker/nginx/sites/default.conf

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    server_name localhost;
    root /var/www/public;
    index index.php index.html index.htm;

    location / {
         try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        try_files $uri /index.php =404;
        fastcgi_pass php-upstream;
        fastcgi_index index.php;
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_read_timeout 600;
        include fastcgi_params;
    }

    location ~ /\.ht {
        deny all;
    }
}

Docker-Compose configuration

We have 3 container definitions, now we just need to setup a Docker-compose configuration to connect all togethers:

# docker/docker-compose.yml
version: '3'

services:
  database:
    build:
      context: ./database
    environment:
      - MYSQL_DATABASE=${DATABASE_NAME}
      - MYSQL_USER=${DATABASE_USER}
      - MYSQL_PASSWORD=${DATABASE_PASSWORD}
      - MYSQL_ROOT_PASSWORD=${DATABASE_ROOT_PASSWORD}
    ports:
      - "3306:3306"
    volumes:
      - ./database/init.sql:/docker-entrypoint-initdb.d/init.sql
      - ./database/data:/var/lib/mysql

  php-fpm:
    build:
      context: ./php-fpm
    depends_on:
      - database
    environment:
      - APP_ENV=${APP_ENV}
      - APP_SECRET=${APP_SECRET}
      - DATABASE_URL=mysql://${DATABASE_USER}:${DATABASE_PASSWORD}@database:3306/${DATABASE_NAME}?serverVersion=5.7
    volumes:
      - ../src:/var/www

  nginx:
    build:
      context: ./nginx
    volumes:
      - ../src:/var/www
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./nginx/sites/:/etc/nginx/sites-available
      - ./nginx/conf.d/:/etc/nginx/conf.d
      - ./logs:/var/log
    depends_on:
      - php-fpm
    ports:
      - "80:80"

And a sample environment variables:

# docker/.env

DATABASE_NAME=symfony
DATABASE_USER=appuser
DATABASE_PASSWORD=apppassword
DATABASE_ROOT_PASSWORD=secret

APP_ENV=dev
APP_SECRET=24e17c47430bd2044a61c131c1cf6990

Symfony

Let’s proceed to the Symfony installation:

$ symfony new src

Play time

Everything is setup correctly! Let’s play with our containers!

$ docker-compose up

When those containers are ready, you can start to open http://localhost, you will see a Symfony 5 welcome screen. Everything works perfectly, have fun!

I’ve create a repository for all the files we talked above https://gitlab.com/martinpham/symfony-5-docker

Secure your Kubernetes application with HTTPS

Martin Pham — Sat, 28 Dec 2019 00:13:02 +0000

Hope you were having fun with my Kubernetes tutorial!

Today, I've got a new comment from Thorsten Hirsch, asking about TLS certificate. Well, @thorstenhirsch, I'm interested as with this thing as well :), and it was the first thing I had to check while I was learning Kubernetes. So I'm gonna share with you guys how did I solve this problem.

Requirement

We'd like to add a TLS certificate to our application, which we built here

Problem

What? problem? there is no problem! we were using certbot thousands times before. Just install it, run a magical script to get a free Let's Encrypt, then config it with nginx.
If you are thinking like this, wait a second and think about this:

Your application lives in read-only containers, managed by Pods. And Pods are added/removed dynamically, by your configurations. And you will need to give nginx certificates when you start it.
You can generate certificates, then pack it within the image, and deloy it. It's a terrible solution. Because you'd need to deploy every time the certificates are gonna expired.
You can store it in a shared volume, and config nginx to take certificates from it. It's another terrible solution. Because you'd still need to manage the certificates yourself (even when you want to run it via a cron?)
...

Solution

Let's try to think about another solution (Spoiler: It's awesome):

We will keep our infrastructure as before, with minimum modifications. No changes to application, no changes to nginx, no changes to deployment.
TLS certificate will be monitored and renewed automatically.

First of all, I'd like to introduce you a new guy - Ingress.

Basically, Ingress is like a Router, which takes the incoming traffic then passes it to the corresponding Service, with the help from Ingress Controllers.

Simple example: You have 3 services:

apple-service (which runs apple.com website, selling fruits)
pineapple-service (another website - pineapple.com, selling phone, tablet, computer,...)
pineapple-cloud-service (offering some cloud services for Pineapple's clients)

What you want is:

apple.com will be pointed to apple-service
pineapple.com will be pointed to pineapple-service
pineapple.com/cloud will be pointed to pineapple-cloud-service

Ingress comes to help you here: Just need to create an Ingress object, with routing rules you want, then point those domains into the Ingress IP. And everything will be handled correctly!

Preparing stuffs

Before everything, we need to prepare stuffs for our Ingress configuration.

Install ingress-nginx
ingress-nginx is a Ingress Controller, which helps Ingress to route the traffic easily.



kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml



kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/cloud-generic.yaml

For this Lab, we'd like to expose the Ingress with the Kube master's IP (192.168.1.33 as we configured before), so let's edit this controller a bit:



kubectl edit svc/ingress-nginx -n ingress-nginx



spec:
  externalIPs:
  - 192.168.1.33

Install cert-manager
cert-manager is a Kubernetes controller, which helps you to manage certificates without pain. We're gonna use it to request & renew Let's encrypt TLS certificate for our application.



kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.12.0/cert-manager.yaml

Check all the pods are running correctly



kubectl get pods --namespace cert-manager

Setup Ingress & TLS

Back to our infrastructure: Before we were using a LoadBalancer as the start point, now we can just change it to stay behind in the cluster, and add an Ingress as the start point.

Before



(Users) ---> Service ---> Pods

Now



(Users) ---> Ingress ---> Service ---> Pods

We're gonna edit a bit the service file service-loadbalancer.yml (We've created it before)



apiVersion: v1
kind: Service
metadata:
  name: service-loadbalancer
spec:
  selector:
    name: templated-pod

  type: ClusterIP
  ports:  
  - name: http
    nodePort: null
    port: 80
    targetPort: 80
    protocol: TCP

  # type: LoadBalancer
  # ports:
  #   - port: 80
  #     targetPort: 80
  # externalIPs:
  #   - 192.168.1.33

Apply it



kubectl apply -f service-loadbalancer.yml

Create a ClusterIssuer
Create new file cert_issuer.yml



apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-site
  namespace: cert-manager
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: YOUR-EMAIL@HERE.TLD
    privateKeySecretRef:
      name: letsencrypt-prod-site
    solvers:
    - http01:
        ingress:
          class: nginx

Apply it



kubectl apply -f cert_issuer.yml

Create an Ingress
Here comes our Rockstar tonight: ingress.yml



apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod-site"

spec:
  tls:
  - hosts:
    - YOUR-DOMAIN-HERE.TLD
    secretName: site-tls

  rules:
  - host: YOUR-DOMAIN-HERE.TLD
    http:
      paths:
      - path: /
        backend:
          serviceName: service-loadbalancer
          servicePort: 80

Nothing special:

Line 12: Define your hostname which will run under this Ingress
Line 16-22: Define a rule, to tell this Ingress: When user browses YOUR-DOMAIN-HERE.TLD, under path /, you'd like to pass him to the service service-loadbalancer on port 80 (defined in service-loadbalancer.yml)

Remember with this Lab, you must point YOUR-DOMAIN-HERE.TLD to your IP address, then forward all traffic on port 80 and 443 to the kube-master IP 192.168.1.33

Show time:



kubectl apply -f ingress.yml

*Note: requesting/renewing a new certificate from Let's encrypt could take some minutes. You can monitor here: *



kubectl describe certificate site-tls

Now you can try to browser https://YOUR-DOMAIN-HERE.TLD/ on your favorite web browser, and open a prosecco :)

I've updated the repository https://gitlab.com/martinpham/kubernetes-fun, so you can take all the files we were talking about.

Having fun with Kubernetes - Final Chapter: Play time

Martin Pham — Mon, 23 Dec 2019 17:45:42 +0000

Finally, you have your very first k8s cluster with 2 nodes up and running well. Now let’s play with it!

(Optional) Install Kubernetes Dashboard

Kubernetes Dashboard is a very cool web-based UI for managing your k8s cluster.

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta6/aio/deploy/recommended.yaml

To access this dashboard, you might need to use proxy

$ kubectl proxy

After that, you can access it by opening
http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/overview?namespace=default

To login, you might need to create an user. However, for this Lab, we can just grab the namespace-controller token to login

$ kubectl -n kube-system describe secret

You will find the namespace-controller token from the output. Copy & Paste it into the dashboard authentication screen, and you will be authenticated.

Putting our Lego blocks

Build and push application image into Docker registry
Go back to our repository, now we’d like to build it again, with version tag. Then push it into our Docker registry. So after it, Kubernetes can pull the image and deploy it.

$ docker build . -t martinpham/kphp:v1
$ docker tag martinpham/kphp:v1 192.168.1.33:5000/martinpham/kphp:v1
$ docker push 192.168.1.33:5000/martinpham/kphp:v1

Here we are building our Docker image, with name martinpham/kphp tag v1 (You can use whatever name you want, don’t worry!). Then push it under name 192.168.1.33:5000/martinpham/kphp:v1

Deploy pods
Create a Configmap configuration file: config.yml

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-config
data:
  nginx.conf: |
    events {
    }
    http {
      server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/html;
        index index.html index.htm index.php;
        server_name _;
        location / {
          try_files $uri $uri/ =404;
        }
        location ~ \.php$ {
          include fastcgi_params;
          fastcgi_param REQUEST_METHOD $request_method;
          fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
          fastcgi_pass 127.0.0.1:9000;
        }
      }
    }

Nothing to scare!, we’re making a shared config across our k8s cluster. You can apply it now:

$ kubectl apply -f config.yml

Now create a Deployment configuration file: deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment
  labels:
    name: deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 2
  selector:
    matchLabels:
      name: templated-pod
  template:
    metadata:
      name: deployment-template
      labels:
        name: templated-pod
    spec:
      volumes:
        - name: app-files
          emptyDir: {}

        - name: nginx-config-volume
          configMap:
            name: nginx-config

      containers:
        - image: 192.168.1.33:5000/martinpham/kphp:v1
          name: app
          volumeMounts:
            - name: app-files
              mountPath: /var/www/html
          lifecycle:
            postStart:
              exec:
                command: ["/bin/sh", "-c", "cp -r /app/. /var/www/html"]
          resources:
            limits:
              cpu: 100m
            requests:
              cpu: 50m


        - image: nginx:latest
          name: nginx
          volumeMounts:
            - name: app-files
              mountPath: /var/www/html
            - name: nginx-config-volume
              mountPath: /etc/nginx/nginx.conf
              subPath: nginx.conf
          resources:
            limits:
              cpu: 100m
            requests:
              cpu: 50m

          ports:
          - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 3
            successThreshold: 1

Ok, it’s a bit spaghetti-style, but again, don’t worry:

Line 6: We tag this deployment as name = deployment
Line 8: We tell k8s to have 3 replicas during deployment.
Line 13: During deployment, k8s must keep at least 1 Pod available, so our website will be still online, ensure zero-downtime during deployment.
Line 21: We’re tagging our future Pod by name = templated-pod, so k8s can find them
Line 24: We create a shared volume between nginx and php, which contains our application runtime
Line 27: We map the config created above into another volume
Line 32: We create a php-fpm container from our created image, and mount the shared volume into /var/www/html
Line 40: We copy all application runtime from the image into the shared volume, so nginx can access it also
Line 41: We define limits cpu for this container
Line 48: We create an nginx container from Docker hub’s nginx office image.
Line 51: We mount the shared volume as we do with the php-fpm container
Line 53: We mount the config mapped above into nginx config file path
Line 63: We expose port 80 to the Pod
Line 64: We define a healthcheck endpoint (HTTP GET /) to tell k8s this Pod is running well or not

Let’s apply it

$ kubectl apply -f deployment.yml

Expose pods with Load Balancer
After applying the Deployment above, k8s will begin to create Pods and exposing them inside k8s network. Now we’d like to expose them via a single Load balancer endpoint.

Create a service-loadbalancer.yml file

apiVersion: v1
kind: Service
metadata:
  name: service-loadbalancer
spec:
  selector:
    name: templated-pod
  ports:
    - port: 80
      targetPort: 80

  type: LoadBalancer
  externalIPs:
    - 192.168.1.33

As told above, all Pods created with the deployment will be tagged as name = templated-pod. We just need to create a Service (Line 2) with type LoadBalancer (Line 12), tell it to balance the traffic to all Pods tagged with name = templated-pod (Line 6 & 7), via the port 80 (Line 9 & 10)

Apply it:

$ kubectl apply -f service-loadbalancer.yml

After applying the Load balancer, you can start to see your application, by browsing http://192.168.1.33 (the Master kube’s IP), great!

Auto-scale pods with Horizontal Pod Autoscaler

Let’s tune our infrastructure by adding a Horizontal Pod Autoscaler. It will automatic scale up / down our Pods depends on CPU/RAM/… usage. Let’s say you want to add 10 minions when traffic is high (CPU > 50%, for example), and reduce to just 3 minions when traffic is low.

Create file hpa.yml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa
spec:
  maxReplicas: 10
  minReplicas: 3
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: deployment
  targetCPUUtilizationPercentage: 50

Nothing special here:

Line 6: Max minions we’re willing to have
Line 7: Minimum minions to serve the website
Line 10-11: Select the target for scaling: we select the Deployment controller, named deployment, as created above

Apply it:

$ kubectl apply -f hpa.yml

Play time

Open the Kubernetes dashboard we installed above and start monitoring our k8s:

Deployment: Try to make a change to the index.php file, then rebuild & push it with tag v2. Then change the deployment.yml (Line 32) to use 192.168.1.33:5000/martinpham/kphp:v2 & apply it. You will see k8s creates 2 pods with new version, while keeping 1 pod with old version & deleting 2 old pods. When finishes, the last old pod will be deleted & another new pod will be created. No downtime during rollout!

Stress-test: Try to send a lot of traffic into the Load balancer endpoint:

$ ab -n 100000 -c 10000 http://192.168.1.33/

You will see k8s monitor all the pod’s cpu, when it crosses 50%, k8s will create up to 10 pods to serve the traffic. Then try to stop the test & wait some moment to see k8s kills the pods when they’re not needed anymore. Everything will be done automatically!

I’ve created a repository contains all the code we talked about here:

https://gitlab.com/martinpham/kubernetes-fun

Have fun! Thank you very much for following my first dev.to tutorial!

Ps.. Small update: I've create an additional tutorial for HTTPS on top of our infrastructure here, hope you like it!

Having fun with Kubernetes - Chapter 4

Martin Pham — Mon, 23 Dec 2019 16:19:44 +0000

From previous chapter, we were talking about the infrastructure which we're gonna build. In this chapter, let’s install & setup a k8s cluster, with 2 nodes!

We will start with the Master server first

For this Lab, I’m gonna use Virtual machines to simulate servers. I’m using macOS Catalina 10.15.2, VMWare Fusion Pro 11.5.1, with 3 Ubuntu 18.04 VMs (2 CPUs, 1GB RAM, bridged network):

kube: master (IP: 192.168.1.33)
kube1: node 1 (IP: 192.168.1.34)
kube2: node 2 (IP: 192.168.1.35)

Before everything, note that:

Kubernetes won’t run if swap enabled
Kubernetes master-nodes communication will require some ports opened
Kubernetes could face some problems with SELINUX

Alright, let’s start with the Master VM.

Master component

$ sudo su

Disable swap

$ swapoff -a

Also don’t forget to disable swap on reboot, by editing /etc/fstab file

(Optional) Set hostname

$ hostnamectl set-hostname kube

(Optional) Set static IP

Edit file /etc/netplan/50-cloud-init.yaml to set static IP

/etc/netplan/50-cloud-init.yaml
network:
    renderer: networkd
    ethernets:
        ens33:
            dhcp4: no
            addresses: [192.168.1.33/24]
            gateway4: 192.168.1.1
            nameservers:
                addresses: [8.8.8.8,8.8.4.4]
    version: 2

Update apt

$ apt update

Install Docker

$ apt install docker.io

Auto start Docker

$ systemctl enable docker && systemctl start docker

Install Kubeadm

$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add

$ apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

$ apt install kubeadm

Init Kubeadm

$ kubeadm init --pod-network-cidr=10.244.0.0/16

After Kubeadm inited, it will give you a command with token to run it on Node servers. It looks like this:

kubeadm join 192.168.1.33:6443 --token xxx --discovery-token-ca-cert-hash xxx

Create k8s config place

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

Create Virtual network

We’re gonna use flannel for Virtual network

$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

(Optional) Create Docker registry

For this Lab, we’re gonna setup a local insecure Docker registry to store our built images.

$ docker run -d -p 5000:5000 --name registry registry:2

For security reasons, Docker doesn’t want to connect to an insecure registry.

To allow Docker to use insecure registry, you need to:

Edit file /etc/docker/daemon.json

/etc/docker/daemon.json
{
        "insecure-registries" : ["192.168.1.33:5000"]
}

Or file /etc/default/docker

/etc/default/docker
DOCKER_OPTS="--insecure-registry 192.168.1.33:5000"

Restart Docker

$ service docker restart

(Remember 192.168.1.33 is our Master server’s IP)

Install metrics server

$ cd /etc
$ git clone https://github.com/kubernetes-incubator/metrics-server.git
$ cd metrics-server/

Edit file /etc/metrics-server/deploy/1.8+/metrics-server-deployment.yaml

      - name: metrics-server
        image: k8s.gcr.io/metrics-server-amd64:v0.3.6
        args:
          - --cert-dir=/tmp
          - --secure-port=4443
        command:
          - /metrics-server
          - --metric-resolution=5s
          - --kubelet-insecure-tls
          - --kubelet-preferred-address-types=InternalIP

Apply it

kubectl apply -f /etc/metrics-server/deploy/1.8+/metrics-server-deployment.yaml

Great! you have a working Master server now. Now we're gonna setup the Node servers and connect them together, just 5 minutes ahead :)

Node component

Let’s start on Kube1 (192.168.1.34)

$ sudo su

Disable swap

$ swapoff -a

To disable swap on reboot, edit /etc/fstab file

(Optional) Set hostname

$ hostnamectl set-hostname kube1

(Optional) Set static IP
Edit file /etc/netplan/50-cloud-init.yaml to set static IP

/etc/netplan/50-cloud-init.yaml
network:
    renderer: networkd
    ethernets:
        ens33:
            dhcp4: no
            addresses: [192.168.1.34/24]
            gateway4: 192.168.1.1
            nameservers:
                addresses: [8.8.8.8,8.8.4.4]
    version: 2

Update apt

$ apt update

Install Docker

$ apt install docker.io

**Auto start Docker

$ systemctl enable docker && systemctl start docker

Install Kubeadm

$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add

$ apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

$ apt install kubeadm

Join this node to the master
This command was generated when you setup your Master server

$ kubeadm join xxx:6443 --token xxx --discovery-token-ca-cert-hash xxx

(Optional) Docker registry

As I told, for some security reasons, Docker doesn’t want to connect to an insecure registry.

To allow Docker to use insecure registry, you need to:

Edit file /etc/docker/daemon.json

/etc/docker/daemon.json
{
        "insecure-registries" : ["192.168.1.33:5000"]
}

Or edit file /etc/default/docker

/etc/default/docker
DOCKER_OPTS="--insecure-registry 192.168.1.33:5000"

Restart Docker

$ service docker restart

Repeat the same, for Kube2 (don’t forget the hostname and static IP)

Done! Now you have a working k8s cluster with Master and 2 Nodes, in the final chapter, we will build our infrastructure on this cluter. And trust me, it's not harder than playing with Lego blocks

The final chapter is here

DEV Community: Martin Pham

Fully type-safe integration between your Laravel backend and your frontend

Why I Built It

The Idea

What It Does

Installation

Configuration

Example: How Your Controller Becomes Typed API Specs

Here's what happens under the hood:

Seamless Integration with Orval for Type-Safe API Clients & Inertia template

What this means for you:

Inertia template

Full Support for Various Data Types

Here's what's happening:

Specifying Request Parameters

1. Route Path Parameters

2. FormRequest Subclasses

3. Docblock Annotations on Controller Methods

Development & Feedback

Building the perfect automated workflows for Blockchain's development

Build workflow for Blockchain's development

Table of Contents

Blockchain is fun!

Problems with our development/deployment

Writing Upgradable smartcontracts with OpenZeppelin

Automatic deployment with Github Actions and Workflows

Memorize Truffle's migration process

Submission Category: DIY Deployments

Yaml File or Link to Code

ActionsHackathon21 / deploy-upgradable-smartcontract-to-blockchain

Deploy upgradable smartcontracts to blockchain

Build documentations

Actions used

Configurations

Configuration

Flows

Automatic build and publish documentations on Github Pages

Build documentations workflow

Submission Category: DIY Deployments

Yaml File or Link to Code

ActionsHackathon21 / build-documentations

Build documentations

Actions used

Configurations

Flows

Configuration

Automatic release new version, and notify your followers about it, using Github workflows

Automatic release new version on tag workflow

Submission Category: DIY Deployments

Yaml File or Link to Code

ActionsHackathon21 / release-on-tag

Release a new version on very tag, then notify your followers on social networks

Release new version on tag

Actions used

Configurations

Configurations

Pre-release

Automatic deployment to GIT branch with GitHub workflow

Deploy application to GIT branch workflow

Submission Category: DIY Deployments

Yaml File or Link to Code

ActionsHackathon21 / deploy-to-git-branch

Use GitHub Actions and Workflows to build and deploy your applications to a branch. So you can just pull this branch to deploy on the production server, without building.

Deploy application to GIT branch

Actions used

Configurations

Flows

Configuration

Coronavirus COVID-19 outbreak dashboard

COVID-19 outbreak is not a hoax anymore

Lacking information

That's why I've decided to build a COVID-19 dashboard

Develop a Telegram chat bot to update Coronavirus COVID-19 situation

TLDR

Coronavirus COVID-19

How I created the bot?

1) Create a bot

2) Write bot's logic

How my bot can send message?

1) Send messages in a chat