Misael  Stark

Misael Stark

1626071280

Docker Containers: Benefits, Usage and Container Commands

In the last tutorial, we briefly touched on the topic of containers and containerizarions. To recall, a container is a standard software unit. It has all the code, and its dependencies packed up in that unit and helps run the application quickly and reliably across the computing environments. So let us discuss Docker containers in this article.

A Docker container is a standalone, lightweight, executable package of software. As already mentioned, since it’s a container, it has everything bundled up together that is needed to run an application like application code, system tools, runtime, binaries, libraries, etc.

As part of Docker containers, we will discuss the following topics in this article.

  • What are Docker containers?
  • Why we need Docker containers?
  • How does a Docker container work?
  • Docker container commands
  • docker run command – launch a container Image/ Run container
  • Next is the docker ps command – List Docker Containers
  • docker commit command – Save Docker containers
  • docker stop command – Stop containers
  • Next is, docker history command – View Docker container history
  • docker top command – View container processes
  • docker rm command – Remove a Container
  • Also, docker stats command – Get the container statistics
  • docker pause command – Pause/unpause a container
  • docker attach command – Attach to a container
  • And, docker kill command – Kill a container
  • How to use privileged Docker containers?
  • Are privileged Docker containers a good idea?
  • How to secure containers?

What are Docker containers?

In our earlier chapter on “Docker Images,” we discussed Docker images in detail. We know that the Docker image is a static entity, and to run the Docker image, we have to associate it with a container. In other words, Docker images become containers at runtime or when they run on Docker Engine.

So a Docker container has the following characteristics:

  • Standard: The Docker containers are portable since they follow the industry standard.
  • Lightweight: Docker containers share the host machine’s OS kernel and hence do not need an OS per application. It reduces licensing and server costs and also gives higher efficiency.
  • Secure: Applications are safer when packaged in Docker containers. Docker also provides the most robust isolation capabilities for its containers in the industry.

Docker containers are the Docker images at runtime and are lightweight, standard, and secure in a nutshell. So when exactly Docker container technology came into existence?

It was in 2013 that the Docker container technology’s launch happened as an open-source Docker Engine.Therefore, one can view the Containers as ‘organizational units’ of Docker. Additionally, we have portable software running in our container. Like cargo ship containers, we can move this container (ship the software), modify, manage, create, remove, or destroy it.

So in simple terms, if the Docker image is a template or blueprint, then the container is a running copy of this image. We can have multiple copies of this image, which means we can have multiple containers with the same image.

#docker #docker containers

What is GEEK

Buddha Community

Docker Containers: Benefits, Usage and Container Commands
Henry Short

Henry Short

1580104680

List all containers in Docker(Docker command)

We can get a list of all containers in docker using docker container list or docker ps commands.

List Docker Containers

To list down docker containers we can use below two commands

  • docker container list
  • docker ps

docker container ls command introduced in docker 1.13 version. In older versions we have to use docker ps command.

List all Containers in docker, using docker ls command

The below command returns a list of all containers in docker.

docker container list -all

or

docker container ls -all

List all containers in docker, using docker ps command

In older version of docker we can use docker ps command to list all containers in docker.

$ docker ps -all

or

$ docker ps -a

List all Running docker containers

The default docker container ls command shows all running docker containers.

$ docker container list

or

$ docker container ls

or

To get list of all running docker containers use the below command

$ docker ps

List all stopped docker containers command

To get list of all stopped containers in docker use the below commands

$ docker container list -f "status=exited"

or

$ docker container ls -f "status=exited"

or you can use docker ps command

$ docker ps -f "status=exited"

List all latest created docker containers

To list out all latest created containers in docker use the below command.

$ docker container list --latest

Show n last created docker containers

To display n last created containers in docker use the below command.

$ docker container list --last=n

#docker #docker-container #docker-command

August  Murray

August Murray

1615008840

Top 24 Docker Commands Explained with Examples

In my previous blog post, I have explained in detail how you can Install Docker and Docker-compose on Ubuntu

In this guide, I have explained the Top 24 Docker Commands with examples.

Make sure you have sudo or root privileges to the system.

Docker Commands

  1. The command to check the version of Docker installed.
  2. To look/search for available docker images from the Docker registry.
  3. To pull docker images from the Docker registry.
  4. Listing all the docker images
  5. Creating / Running docker container from Docker image.
  6. To list the actively running docker containers.
  7. To list all the docker containers
  8. To stop a Container
  9. To start a Container
  10. To restart a Docker container
  11. To login to running Docker container
  12. To delete the stopped Docker containers
  13. To delete Docker images from the Local system
  14. To check logs of a running Docker container
  15. Killing docker containers
  16. Log in to Docker Hub registry (hub.docker.com)
  17. Removing docker hub registry login from the system.
  18. Check active resource usage by each containers
  19. Rename a Docker container
  20. To display system wide information of Docker
  21. Inspecting a Docker container
  22. Building docker images from Docker file
  23. Creating new docker images from a Container
  24. Pushing Docker images from Local to Docker registry.

#docker #docker-command #containers #docker-compose #docker-image

Leonard  Paucek

Leonard Paucek

1656280800

Jump to Local IDE Code Directly From Browser React Component

React Dev Inspector

Jump to local IDE code directly from browser React component by just a simple click

This package allows users to jump to local IDE code directly from browser React component by just a simple click, which is similar to Chrome inspector but more advanced.

View Demo View Github

Preview

press hotkey (ctrl⌃ + shift⇧ + commmand⌘ + c), then click the HTML element you wish to inspect.

screen record gif (8M size):

Jump to local IDE code directly from browser React component by just a simple click

Installation

npm i -D react-dev-inspector

Usage

Users need to add React component and apply webpack config before connecting your React project with 'react-dev-inspector'.

Note: You should NOT use this package, and React component, webpack config in production mode


 

1. Add Inspector React Component

import React from 'react'
import { Inspector, InspectParams } from 'react-dev-inspector'

const InspectorWrapper = process.env.NODE_ENV === 'development'
  ? Inspector
  : React.Fragment

export const Layout = () => {
  // ...

  return (
     {}}
      onClickElement={(params: InspectParams) => {}}
    >
     
       ...
     
    
  )
}


 

2. Set up Inspector Config

You should add:

  • an inspector babel plugin, to inject source code location info
    • react-dev-inspector/plugins/babel
  • an server api middleware, to open local IDE
    • import { launchEditorMiddleware } from 'react-dev-inspector/plugins/webpack'

to your current project development config.

Such as add babel plugin into your .babelrc or webpack babel-loader config,
add api middleware into your webpack-dev-server config or other server setup.


 

There are some example ways to set up, please pick the one fit your project best.

In common cases, if you're using webpack, you can see #raw-webpack-config,

If your project happen to use vite / nextjs / create-react-app and so on, you can also try out our integrated plugins / examples with

raw webpack config

Example:

// .babelrc.js
module.exports = {
  plugins: [
    /**
     * react-dev-inspector plugin, options docs see:
     * https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
     */
    'react-dev-inspector/plugins/babel',
  ],
}
// webpack.config.ts
import type { Configuration } from 'webpack'
import { launchEditorMiddleware } from 'react-dev-inspector/plugins/webpack'

const config: Configuration = {
  /**
   * [server side] webpack dev server side middleware for launch IDE app
   */
  devServer: {
    before: (app) => {
      app.use(launchEditorMiddleware)
    },
  },
}


 

usage with Vite2

example project see: https://github.com/zthxxx/react-dev-inspector/tree/master/examples/vite2

example vite.config.ts:

import { defineConfig } from 'vite'
import { inspectorServer } from 'react-dev-inspector/plugins/vite'

export default defineConfig({
  plugins: [
    inspectorServer(),
  ],
})


 

usage with Next.js

use Next.js Custom Server + Customizing Babel Config

example project see: https://github.com/zthxxx/react-dev-inspector/tree/master/examples/nextjs

in server.js, example:

...

const {
  queryParserMiddleware,
  launchEditorMiddleware,
} = require('react-dev-inspector/plugins/webpack')

app.prepare().then(() => {
  createServer((req, res) => {
    /**
     * middlewares, from top to bottom
     */
    const middlewares = [
      /**
       * react-dev-inspector configuration two middlewares for nextjs
       */
      queryParserMiddleware,
      launchEditorMiddleware,

      /** Next.js default app handle */
        (req, res) => handle(req, res),
    ]

    const middlewarePipeline = middlewares.reduceRight(
      (next, middleware) => (
        () => { middleware(req, res, next) }
      ),
      () => {},
    )

    middlewarePipeline()

  }).listen(PORT, (err) => {
    if (err) throw err
    console.debug(`> Ready on http://localhost:${PORT}`)
  })
})

in package.json, example:

  "scripts": {
-    "dev": "next dev",
+    "dev": "node server.js",
    "build": "next build"
  }

in .babelrc.js, example:

module.exports = {
  plugins: [
    /**
     * react-dev-inspector plugin, options docs see:
     * https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
     */
    'react-dev-inspector/plugins/babel',
  ],
}


 

usage with create-react-app

cra + react-app-rewired + customize-cra example config-overrides.js:

example project see: https://github.com/zthxxx/react-dev-inspector/tree/master/examples/cra

const { ReactInspectorPlugin } = require('react-dev-inspector/plugins/webpack')
const {
  addBabelPlugin,
  addWebpackPlugin,
} = require('customize-cra')

module.exports = override(
  addBabelPlugin([
    'react-dev-inspector/plugins/babel',
    // plugin options docs see:
    // https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
    {
      excludes: [
        /xxxx-want-to-ignore/,
      ],
    },
  ]),
  addWebpackPlugin(
    new ReactInspectorPlugin(),
  ),
)


 

usage with Umi3

example project see: https://github.com/zthxxx/react-dev-inspector/tree/master/examples/umi3

Example .umirc.dev.ts:

// https://umijs.org/config/
import { defineConfig } from 'umi'

export default defineConfig({
  plugins: [
    'react-dev-inspector/plugins/umi/react-inspector',
  ],
  inspectorConfig: {
    // babel plugin options docs see:
    // https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
    excludes: [],
  },
})


 

usage with Umi2

Example .umirc.dev.js:

import { launchEditorMiddleware } from 'react-dev-inspector/plugins/webpack'

export default {
  // ...
  extraBabelPlugins: [
    // plugin options docs see:
    // https://github.com/zthxxx/react-dev-inspector#inspector-babel-plugin-options
    'react-dev-inspector/plugins/babel',
  ],

  /**
   * And you need to set `false` to `dll` in `umi-plugin-react`,
   * becase these is a umi2 bug that `dll` cannot work with `devServer.before`
   *
   * https://github.com/umijs/umi/issues/2599
   * https://github.com/umijs/umi/issues/2161
   */
  chainWebpack(config, { webpack }) {
    const originBefore = config.toConfig().devServer

    config.devServer.before((app, server, compiler) => {
      
      app.use(launchEditorMiddleware)
      
      originBefore?.before?.(app, server, compiler)
    })

    return config  
  },
}

usage with Ice.js

Example build.json:

// https://ice.work/docs/guide/basic/build
{
  "plugins": [
    "react-dev-inspector/plugins/ice",
  ]
}


 

Examples Project Code


 

Configuration

Component Props

checkout TS definition under react-dev-inspector/es/Inspector.d.ts.

PropertyDescriptionTypeDefault
keysinspector hotkeys

supported keys see: https://github.com/jaywcjlove/hotkeys#supported-keys
string[]['control', 'shift', 'command', 'c']
disableLaunchEditordisable editor launching

(launch by default in dev Mode, but not in production mode)
booleanfalse
onHoverElementtriggered when mouse hover in inspector mode(params: InspectParams) => void-
onClickElementtriggered when mouse hover in inspector mode(params: InspectParams) => void-
// import type { InspectParams } from 'react-dev-inspector'

interface InspectParams {
  /** hover / click event target dom element */
  element: HTMLElement,
  /** nearest named react component fiber for dom element */
  fiber?: React.Fiber,
  /** source file line / column / path info for react component */
  codeInfo?: {
    lineNumber: string,
    columnNumber: string,
    /**
    * code source file relative path to dev-server cwd(current working directory)
    * need use with `react-dev-inspector/plugins/babel`
    */
    relativePath?: string,
    /**
    * code source file absolute path
    * just need use with `@babel/plugin-transform-react-jsx-source` which auto set by most framework
    */
    absolutePath?: string,
  },
  /** react component name for dom element */
  name?: string,
}


 

Inspector Babel Plugin Options

interface InspectorPluginOptions {
  /** override process.cwd() */
  cwd?: string,
  /** patterns to exclude matched files */
  excludes?: (string | RegExp)[],
}


 

Inspector Loader Props

// import type { ParserPlugin, ParserOptions } from '@babel/parser'
// import type { InspectorConfig } from 'react-dev-inspector/plugins/webpack'

interface InspectorConfig {
  /** patterns to exclude matched files */
  excludes?: (string | RegExp)[],
  /**
   * add extra plugins for babel parser
   * default is ['typescript', 'jsx', 'decorators-legacy', 'classProperties']
   */
  babelPlugins?: ParserPlugin[],
  /** extra babel parser options */
  babelOptions?: ParserOptions,
}


 

IDE / Editor config

This package uses react-dev-utils to launch your local IDE application, but, which one will be open?

In fact, it uses an environment variable named REACT_EDITOR to specify an IDE application, but if you do not set this variable, it will try to open a common IDE that you have open or installed once it is certified.

For example, if you want it always open VSCode when inspection clicked, set export REACT_EDITOR=code in your shell.


 

VSCode

install VSCode command line tools, see the official docs
install-vscode-cli

set env to shell, like .bashrc or .zshrc

export REACT_EDITOR=code


 

WebStorm

  • just set env with an absolute path to shell, like .bashrc or .zshrc (only MacOS)
export REACT_EDITOR='/Applications/WebStorm.app/Contents/MacOS/webstorm'

OR

install WebStorm command line tools
Jump to local IDE code directly from browser React component by just a simple click

then set env to shell, like .bashrc or .zshrc

export REACT_EDITOR=webstorm


 

Vim

Yes! you can also use vim if you want, just set env to shell

export REACT_EDITOR=vim


 

How It Works

Stage 1 - Compile Time

  • [babel plugin] inject source file path/line/column to JSX data attributes props

Stage 2 - Web React Runtime

[React component] Inspector Component in react, for listen hotkeys, and request api to dev-server for open IDE.

Specific, when you click a component DOM, the Inspector will try to obtain its source file info (path/line/column), then request launch-editor api (in stage 3) with absolute file path.

Stage 3 - Dev-server Side

[middleware] setup launchEditorMiddleware in webpack dev-server (or other dev-server), to open file in IDE according to the request params.

Only need in development mode,and you want to open IDE when click a component element.

Not need in prod mode, or you just want inspect dom without open IDE (set disableLaunchEditor={true} to Inspector component props)

Analysis of Theory


Author: zthxxx
Source code: https://github.com/zthxxx/react-dev-inspector
License: MIT license

#react-native #react 

Misael  Stark

Misael Stark

1626071280

Docker Containers: Benefits, Usage and Container Commands

In the last tutorial, we briefly touched on the topic of containers and containerizarions. To recall, a container is a standard software unit. It has all the code, and its dependencies packed up in that unit and helps run the application quickly and reliably across the computing environments. So let us discuss Docker containers in this article.

A Docker container is a standalone, lightweight, executable package of software. As already mentioned, since it’s a container, it has everything bundled up together that is needed to run an application like application code, system tools, runtime, binaries, libraries, etc.

As part of Docker containers, we will discuss the following topics in this article.

  • What are Docker containers?
  • Why we need Docker containers?
  • How does a Docker container work?
  • Docker container commands
  • docker run command – launch a container Image/ Run container
  • Next is the docker ps command – List Docker Containers
  • docker commit command – Save Docker containers
  • docker stop command – Stop containers
  • Next is, docker history command – View Docker container history
  • docker top command – View container processes
  • docker rm command – Remove a Container
  • Also, docker stats command – Get the container statistics
  • docker pause command – Pause/unpause a container
  • docker attach command – Attach to a container
  • And, docker kill command – Kill a container
  • How to use privileged Docker containers?
  • Are privileged Docker containers a good idea?
  • How to secure containers?

What are Docker containers?

In our earlier chapter on “Docker Images,” we discussed Docker images in detail. We know that the Docker image is a static entity, and to run the Docker image, we have to associate it with a container. In other words, Docker images become containers at runtime or when they run on Docker Engine.

So a Docker container has the following characteristics:

  • Standard: The Docker containers are portable since they follow the industry standard.
  • Lightweight: Docker containers share the host machine’s OS kernel and hence do not need an OS per application. It reduces licensing and server costs and also gives higher efficiency.
  • Secure: Applications are safer when packaged in Docker containers. Docker also provides the most robust isolation capabilities for its containers in the industry.

Docker containers are the Docker images at runtime and are lightweight, standard, and secure in a nutshell. So when exactly Docker container technology came into existence?

It was in 2013 that the Docker container technology’s launch happened as an open-source Docker Engine.Therefore, one can view the Containers as ‘organizational units’ of Docker. Additionally, we have portable software running in our container. Like cargo ship containers, we can move this container (ship the software), modify, manage, create, remove, or destroy it.

So in simple terms, if the Docker image is a template or blueprint, then the container is a running copy of this image. We can have multiple copies of this image, which means we can have multiple containers with the same image.

#docker #docker containers

Mikel  Okuneva

Mikel Okuneva

1602317778

Ever Wondered Why We Use Containers In DevOps?

At some point we’ve all said the words, “But it works on my machine.” It usually happens during testing or when you’re trying to get a new project set up. Sometimes it happens when you pull down changes from an updated branch.

Every machine has different underlying states depending on the operating system, other installed programs, and permissions. Getting a project to run locally could take hours or even days because of weird system issues.

The worst part is that this can also happen in production. If the server is configured differently than what you’re running locally, your changes might not work as you expect and cause problems for users. There’s a way around all of these common issues using containers.

What is a container

A container is a piece of software that packages code and its dependencies so that the application can run in any computing environment. They basically create a little unit that you can put on any operating system and reliably and consistently run the application. You don’t have to worry about any of those underlying system issues creeping in later.

Although containers were already used in Linux for years, they became more popular in recent years. Most of the time when people are talking about containers, they’re referring to Docker containers. These containers are built from images that include all of the dependencies needed to run an application.

When you think of containers, virtual machines might also come to mind. They are very similar, but the big difference is that containers virtualize the operating system instead of the hardware. That’s what makes them so easy to run on all of the operating systems consistently.

What containers have to do with DevOps

Since we know how odd happenings occur when you move code from one computing environment to another, this is also a common issue with moving code to the different environments in our DevOps process. You don’t want to have to deal with system differences between staging and production. That would require more work than it should.

Once you have an artifact built, you should be able to use it in any environment from local to production. That’s the reason we use containers in DevOps. It’s also invaluable when you’re working with microservices. Docker containers used with something like Kubernetes will make it easier for you to handle larger systems with more moving pieces.

#devops #containers #containers-devops #devops-containers #devops-tools #devops-docker #docker #docker-image