nginx

背景 本人平时的工作有一部分是编译Android系统，Android官方推荐的内存配置是16G，旧电脑的内存是16G，完整编译一次LineageOS 14.1(对应的Android版本是7.1.1)，大概需要两个小时左右，编译LineageOS 17.1(对应的Android版本是10)，大概需要4个小时，而且编译途中，还不能干别的事，否则会导致资源紧张而编译失败，因此需要升级一下硬件配置。 环境 硬件，由ThinkPad T580 升级到 外星人Area 51M顶配版。 系统，两个都是ArchLinux。 文件总大小有600G左右。 文件复制的过程 在旧电脑安装了Nginx，准备用Nginx作为服务器，新电脑使用Http从旧电脑下载文件，达到迁移文件的目的，这个速度只有5M左右，原因可能是两台电脑都使用内网WIFI，而路由器i的内网转发限制到了很低，应该是5M，这个方案放弃。 在旧电脑安装vsftpd，新电脑使用ftp下载文件，但是这个方案的速度也是只有5M，原因同上，放弃。 使用网线将两台电脑直连(网线是6类，水晶头是超5类)，旧电脑设置ip相关参数，ip地址: 192.168.1.1，子网掩码: 255.255.255.0，网关: 192.168.1.1，新电脑ip地址: 192.168.1.2，子网掩码和网关同旧电脑一致，然后使用rsync从旧电脑给新电脑同步数据

个人博客地址： http://www.mwbdtth.club/ 选择题可能有些题目有点小问题，请酌情参考，主要还是以实操为主 单选题(200分): 1.下面关于软件项目开发过程，叙述错误的是？(10分) A、敏捷开发从需求、计划、开发、测试，直到项目结束，整个周期一直在迭代中 B、敏捷开发中开发、测试、发布又可以单独迭代多次 C、瀑布式模型分为计划、分析、设计、程序开发、测试、修改和整合，一个阶段结束，另一个阶段接着开始 D、瀑布式模型着重迭代式开发，分析、设计、开发、测试和发布(正确答案) 2.敏捷开发从需求、计划、开发、测试，直到项目结束，整个周期一直在迭代中，而其中可以单独迭代多次的不包括哪个过程？(10分) A、开发 B、测试 C、计划(正确答案) D、发布 3.以下关于STP协议的描述中，哪项是正确的？ (10分) A、STP运行在交换机和网桥设备上 B、STP协议是一个二层链路管理协议 C、STP在选定根网桥，让一些端口进入阻塞工作模式，这些被阻塞端口没有被激活(正确答案) D、STP的主要功能是在保证网络中没有回路的基础上，允许在第二层链路中提供冗余路径 4.以下哪个状态不是RSTP的工作状态？ (10分) A、监听状态(正确答案) B、丢弃状态 C、转发状态 D、学习状态 5.在常用的数据库表单管理命令当中，“use 数据库；”名称的作用是？(10分) A

1. nginx安装 在Linux中安装依赖 sudo yum -y install openssl openssl-devel pcre pcre-devel zlib zlib-devel gcc gcc-c++ 解压nginx的tar包，然后在解压目录里面依次执行 1) ./configure --with-stream --prefix=/opt/module/nginx # 指定安装路径 --with-stream:编译时安装stream模块 2) make 3) make install 或者直接执行 ./configure --with-stream --prefix=/opt/module/nginx make && make install 在安装路径下修改配置文件 ./conf/nginx.conf stream模块与http模块是平级的 stream { upstream rtmp { server 192.168.11.40:7777; # 这里配置成要实现负载均衡的地址 server 192.168.11.41:7777; server 192.168.11.42:7777; server { listen 7777; # 需要nginx服务本地监听的端口 proxy_timeout 20s; proxy_pass rtmp; } } 启动nginx服务

1、为什么K8s要引入deployment资源。 答：deployment也是保证pod高可用的一种方式，明明已经有RC(Replication Controller)，为什么还要引入deployment呢？是因为deployment解决了RC(Replication Controller)的一个痛点。是因为RC在进行版本升级的时候，会造成一个问题，就是它的svc(Service)短时间内访问不了了，deployment就是解决这个问题的。 2、创建一个deployment的配置文件。 声明api的版本。 apiVersion: extensions/v1beta1 kind代表资源的类型，资源是Deployment。 kind: Deployment 资源叫什么名字，是在其属性metadata里面的。 metadata: 第一个属性name的值是myweb，即Service的名字就叫做myweb。 name: nginx-deployment spec是详细，详细里面定义了一个容器。 spec: 副本的数量，比RC少了一个selector。 replicas: 3 模板，都是使用模板来启动Pod的。 template: 资源叫什么名字，是在其属性metadata里面的。 metadata: # 给Pod贴上了一个标签，标签是app: nginx，标签是有一定的作用的。

今天博主使用typecho各种不爽，索性干掉typecho，使用WordPress 依赖 mysql nginx yml 文件 version: '3' services: nginx: image: nginx:1.13.9-alpine ports: - "80:80" - "443:443" restart: always volumes: - ./wordpress.conf:/etc/nginx/conf.d/default.conf - ./nginx_logs:/var/log/nginx - ./letsencrypt:/etc/letsencrypt depends_on: - wordpress networks: - daryl_blog_net wordpress: image: wordpress:latest restart: always volumes: - ./html:/var/www/html networks: - daryl_blog_net depends_on: - db environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: password db: image: mysql:5.7.23 volumes:

一、背景介绍 前段时间小编给大家分享了： 1、 《五分钟打造高逼格的监控系统》 2、 《Prometheus服务监控进阶》 我们对Prometheus（普罗米修斯）监控体系有了整体的了解。监控的基础是对各类服务的信息、数据进行采样收集，这一重要的角色就是Prometheus里的Exporter。Exporter是我们最常打交道的模块，本节为大家介绍Exporter和其常用的组件。 二、Exporter详细介绍 广义上讲所有可以 向Prometheus提供监控样本数据的程序 都可以被称为一个Exporter。而Exporter的一个实例称为target，如下所示，Prometheus通过 轮询 的方式定期从这些target中获取样本数据: 从Exporter的来源上来讲，主要分为两类： 社区提供的 Prometheus社区提供了丰富的Exporter实现，涵盖了从基础设施，中间件以及网络等各个方面的监控功能。这些Exporter可以实现大部分通用的监控需求。下表列举一些社区中常用的Exporter： 户自定义的 除了直接使用社区提供的Exporter程序以外，用户还可以基于Prometheus提供的Client Library创建自己的Exporter程序，目前Promthues社区官方提供了对以下编程语言的支持：Go、Java/Scala、Python、Ruby。 独立研发的产品

一、官方介绍 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ Deployment为Pod和Replica Set提供声明式更新。 你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。 注意：您不该手动管理由 Deployment 创建的 Replica Set，否则您就篡越了 Deployment controller 的职责！下文罗列了 Deployment 对象中已经覆盖了所有的用例。如果未有覆盖您所有需要的用例，请直接在 Kubernetes 的代码库中提 issue。 二、Deployment可以帮我们做什么 定义一组Pod期望数量，Controller会维持Pod数量与期望数量一致 配置Pod的发布方式，controller会按照给定的策略更新Pod，保证更新过程中不可用Pod维持在限定数量范围内 如果发布有问题支持回滚 三、Deployment原理 控制器模型 在Kubernetes架构中，有一个叫做kube

现如今微服务架构十分流行，而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时，支持微服务的技术栈也是多种多样的，本系列文章主要介绍这些技术中的翘楚——Spring Cloud。这是序篇，主要讲述我们为什么选择Spring Cloud和它的技术概览。 1、为什么微服务架构需要Spring Cloud 简单来说，服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB），并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈，而Spring Cloud就是其中的佼佼者。 DevOps是英文Development和Operations的合体，他要求开发、测试、运维进行一体化的合作，进行更小、更频繁、更自动化的应用发布，以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚，也方便运维和管理。这个理念与微服务理念不谋而合。 接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。点击 这里 查看Spring系列教程集合。 1.1 从使用nginx说起 最初的服务化解决方案是给提供相同服务提供一个统一的域名，然后服务调用者向这个域名发送HTTP请求，由Nginx负责请求的分发和跳转。 这种架构存在很多问题： Nginx作为中间层

一： <IfModule mod_rewrite.c> 　　RewriteEngine on 　　RewriteCond %{SERVER_PORT} !^443 　　RewriteCond %{REQUEST_FILENAME} !-f 　　RewriteCond %{REQUEST_FILENAME} !-d 　　RewriteRule ^(.*)/$ /public/$1 [L,R=301] 　　RewriteRule ^ index.php [L] </IfModule> 二： 　　 　　 Web 服务器配置 关于虚拟主机的配置（映射域名到Laravel应用目录）略过，如果了解细节可参考 这篇教程 ，当然也可以留待下一篇讲 Homestead 和 Valet 再去了解。本文只探讨如何美化 URL 让其更具有可读性。 Apache 框架中自带的 public/.htaccess 文件支持隐藏 URL 中的 index.php ，如过你的 Laravel 应用使用 Apache 作为服务器，需要先确保 Apache 启用了 mod_rewrite 模块以支持 .htaccess 解析。 如果 Laravel 自带的 .htaccess 文件不起作用，试试将其中内容做如下替换： Options +FollowSymLinks RewriteEngine On

前言 去年在学习docker，在看完菜鸟教程和第一本docker书后，一直想实战用一下这个技术，多用用才能熟能生巧，真正体验它的利弊。正好傅老板用docker搭完了wordpress，我也就手痒跟着搭建了一下（也就是现在的这个博客网站）。 此处记录一下搭建过程。 搭建环境 阿里云ECS 去年双11买的，720/3年，1核1G1M香港服务器，centos 7.4 有个小插曲，阿里云的工作人员还给我打电话，问我用的怎么样。。阿里云什么时候有这种回访了。。。 域名 阿里云购买即可，像我申请的 .top 域名更是便宜，丧心病狂只要2块钱。。 ssl证书 https用的证书，我是在腾讯云免费申请的，地址为： 腾讯云证书管理 ，此处就不详细描述申请过程了，很简单的 Docker 这里要注意，centos中不要直接使用yum install docker，yum中的是旧的docker版本，升级参考我的这篇博文： CentOS更新Docker至最新版本 Docker Compose compose原本是一个第三方公司写的，用来在docker中定义和运行复杂应用的小工具，后来被docker收购了，正式用来替代最早的fig。 通过以下命令安装： # 下载compose curl -L https://github.com/docker/compose/releases/download/1.18.0