Skip to main content

2 posts tagged with "Website"

View All Tags

· 7 min read
CheverJohn

今天是版本第一次上线的日子,值得庆祝!然后我想就我第一次上线做一下记录工作。

项目简介

本项目就是个博客系统,主要功能就是每天记录下我的个人博客、技术心得。其中加入了一个原生的评论功能、侧边栏系统、热评系统、基本的博客系统。
利用的是拿手的Django(3.2.3)框架,前端是用了Django模板引擎,后边会改进成vue的框架。

项目部署

使用的是一台阿里云的轻量应用服务器。 基本部署思路是: 本地

  • 1.本地将代码上传到github仓库中去。

  • 2.本地将项目进行打包,使用python setup.py 命令,本来是准备上线到私有pypiserver的,但是后来还是直接把打包好的项目(mr8god_blog_website-0.1-py3-none-any.whl)通过ftp工具(mobaxterm)上传到了服务器。在服务器中使用pip install mr8god_blog_website-0.1-py3-none-any.whl命令将其安装,对了对了,前提是激活了虚拟环境哦。 服务器端

    • 2.1.使用root账户部署代码不够安全,所以创建了一个blog用户,将用户加入到超级用户组,然后开始部署项目。
    • 2.2.因为centos7系统自带的sqlite版本低于django所要求的最低版本,所以首先来更新sqlite3的版本。
    • 2.3.安装python3,这边选择python3.6,安装方法就不多介绍了,这个不难。
  • 3.使用blog账号,在/home/blog中创建文件夹blogsrc/website/website/settings/base.py(我相信这样进行设置,大家应该都能明白是什么意思了)。很清楚的就可以看到我的文件夹是怎么样子的。在/blogsrc这个文件夹里git clone 云端github仓库中的代码。

  • 4.部署代码的时候,需要在settings文件中修改ALLOWED_HOSTS值,可以修改为ALLOWED_HOSTS=['127.0.0.1','localhost','.mr8god.cn','101.132.184.191']指定了 ALLOWED_HOSTS 的值后,django 将只允许通过指定的域名访问我们的应用,比如这里只允许通过 127.0.0.1,localhost 以及 zmrenwu.com 和其任意子域名(域名前加一个点表示允许访问该域名下的子域名)访问(即 HTTP 报文头部中 Host 的值必须是以上指定的域名,通常你在浏览器输入域名访问网站时,Host 的值就会被设置为网站的域名),这样可以避免 HTTP Host 头攻击。

  • 5.还需要做的一件事是collectstatic,顾名思义,就是收集静态文件,这个需要打开设置文件中的STATIC_ROOT=os.path.join(BASE_DIR,'static') 意思就是自动生成静态文件在BASE_DIR下会有一个static的文件夹,里边全都是静态文件。 注意!这个文件夹不会被上传到github上去,这就意味着,你在服务器中还需要输入manage.py collectstatic这个命令。 对了,你还得在nginx服务器配置中配置好这个static文件夹。

  • 6.因为数据库文件没有带下来(没有上传到github上去)所以,还是得运行makemigration和migrate,还有createsuperuser。这个时候,可以通过manage.py runserver 进行一个测试开发服务器是否能正常启动。

  • 7.使用Gunicorn,在生产环境中,使用流行的Gunicorn来其启动可以用于线上环境的服务器。当然这里边要涉及一个Gunicorn的安装,安装很简单,以虚拟环境身份进行一个安装即可,同样,setup也是以虚拟环境进行安装。 gunicorn website.wsgi -w 2 -k gthread -b 0.0.0.0:8000 先进行一个这么的启动,待会再和nginx一起进行supervisor的后台管理哈。

  • 8.安装配置Nginx 以最简单的方法安装好nginx, nginx自己的配置文件在/etc/nginx/nginx.conf 配置文件中有这么一句话,include /etc/nginx/default.d/*.conf 意思就是在/etc/nginx/conf.d文件夹中只要是以.conf结尾的文件,都会识破并进行一个解析。 所以我们就得好好配置/etc/nginx/conf.d文件夹下的文件,比如说我们这个项目,我在里边的配置文件是hellomyblog.conf,该文件里有两个参数我进行了配置,server_name和location /static{ alias xxxx},前者决定了什么样的域名可以访问本项目,后者决定了nginx进行拦截解析的static文件位置。

  • 9.使用Supervisor进行管理进程,重点 现在Gunicorn和我们手工启动的,如果我们推出shell,服务器就关闭了,博客就无法访问了,就算在后台启动Gunicorn,万一哪天服务器崩溃重启了又得重新登录服务器去进行一个Gunicorn的启动,这就很不舒服了。为此,使用Supervisor来管理Gunicorn进程。这样当服务器重新启动或者Gunicorn进程意外崩溃后,Supervisor会帮我们自动重启Gunicorn。 首先还是使用我们的虚拟环境安装一个Supervisor。关于这个软件的配置文件,据我的目前理解就是,当我们运行完pip install supervisor之后,在/etc文件夹里会有supervisord.d文件夹和supervisord.conf。前者里边包含了supervisor需要启动的应用的配置文件,后者是supervisor本身的配置文件。 这边拿我写的一个pypiserver的配置文件做示范: [program:pypi-server] directory=/home/pypiserver/ command=/home/pypiserver/.venv/bin/pypi-server -p 18080 -P /home/pypiserver/.htaccess /home/pypiserver/packages autostart=true autorestart=true redirect_stderr=true 里边有我的命令(command)实际上也就这个命令需要进行一个配置。

    这边还需要配置的就是gunicorn了
    首先从github git clone本项目下来。
    2.创建虚拟环境,

    gunicorn website.wsgi -w 2 -k gthread -b 0.0.0.0:8000

· 19 min read
CheverJohn

这是一种基于github托管平台的工具类系统,我们以Travis CI来讲这一项技术的实现。

什么是Continuous Integration(CI)呢?

这是一种在小周期内寻求经常合并代码的一种模式。 与此相对的就是,在一个大的开发周期结束后进行合并的另一种模式。

CI的目标就是以较小的增量开发,一点点的增加自己的代码和经常性的测试,从而构建更加稳定和优秀的软件开发。

​ Travis CI通过自动化生成并且测试代码的改变来实现对我们开发进程的一种帮助。而且如果成功实现了改变,它还能够提供实时的反馈。

​ Travis CI也能在你的程序开发中的其他部分提供帮助,通过管理部署通知

CI的构建以及自动化:Building,Testing,Deploying

​ 当你使用了Build的功能后,Travis CI将会从你的github仓库拉下你的代码,并把它放在一个全新的虚拟环境中。然后执行一系列的build命令进而test你的代码。

​ 如果你的代码test没通过,那么build将会被认为是失败了的;相反如果通过了,build就是成功的,系统便会将代码部署到你想让它部署的地方去。

​ CI build可以自动化你的动作流的其他部分。这就意味着你可以使你的任务和其它的一些部分相互依赖起来,通过Build Stages,设置notifications,准备deployments在你build之后或者更多其他的任务之后的方法。

Builds,Jobs,Stages and Phases

这里是对上面几个名词的解释

  • phase - 这是指一种继往开来的工作模式。举个例子,我们首先要做好deploy部署好阶段,然后我们才关注script阶段,最后我们才能够实现install阶段。
  • job - 一种自动化的进程就是一个job,我举一个例子哈,我们从我们的远程仓库将代码clone下来,clone到一个虚拟环境中去,接下来我们开始执行一系列的阶段比如说编译代码、跑代码测试等等。当然如果我们的job中有一个步骤出现了错误,那么我们的script阶段就会向我们返回一个值来报错。
  • build - 一组jobs。举个例子,一个build命令下可能会有2个jobs,每个jobs都会用各自适合的编程语言来进行测试项目。一个build的完成,也就意味着它的jobs都被成功完成了。
  • stage - 由多个阶段组成的顺序生成过程的一部分并行运行,就称为一组作业

Breaking the Build

当满足一下条件的时候,我们就认为build已经损坏了。(比如说一个或多个作业完成且状态未通过时:

  • errored - 我们在before_install,install, before_script阶段输错了命令导致返回了一串错误代码。这个job就会立刻停止。
  • failed - 在script阶段的一个命令导致返回了错误代码。这个job会继续跑知道它完成了它的工作。
  • canceled - 管理员取消了job

Infrastructure and Environment Notes

对于不同的操作系统,有不同的要求

  • Linux - 以后有用再去官方文档查
  • macos - 同上
  • Windows - 系统版本在1803以上。

Travis CI是在软件开发领域中的一个在线的、分布式的持续集成服务,用来测试在github托管的代码的。好吧上面所有的build可以替换成构建。

开始讲解Travis CI和github page运行机制原理

宝贝们,上面都是我对官方文档的翻译哦,我觉得不是特别妥 现在才是最重要的部分,是精髓哦!我花了(让我算算哈,从早上8:15到现在22:53)14个小时38分钟。是真的“有意思哦”!

闲话少说,开始了

首先得感谢我桃大佬的概念输出,大概是上上周吧,建议我为了我博客的安全着想,将本地的博客配置文件保存到云端,如果本地的硬盘出了啥问题的话,我们也可以从云端恢复数据,完美的主意!桃大佬给了我可持续集成这一概念的输出。

概念输出:什么是可持续集成(CI)呢?

这个网上都能给出正确的解释,这是一种在线托管的持续集成服务,与github是好哥们,当我们用github账号登录了Travis CI(CI的一种)之后,我们就可以看到介家伙上面有所有我们github仓库中的项目。是的呢,就是和github穿一条裤子的呢!我先放图哈!

Travis介绍_一_.jpg

大家可以从图中很容易的看到,我Mr8god在GitHub上的仓库这边都有。概念我也说了,大致样子也给大家看了,我们开始下一步。

Travis CI和GitHub的机制原理

先放图,这是我自己做的图解

Travis CI和GitHub的机制原理.jpg

这一张图可以很好的解释哈,我这边也懒得加水印啥的,想拿就拿。

不管是啥机制,首先的前提是你的思路一定要明确,这也就是为什么网上教程有很多,但是很少有人能够做得出来的原因。大多数人只喜欢找现成的就满足了。但是那些都是治标不治本的玩意儿,真东西还是得往细了研究,以前都觉得那些花里胡哨的东西真好玩,可真等到我玩过了之后才发现,基础才是最重要的东西!!!不禁想到了很多人很早学习了框架……咳咳,不扯远了不扯远不扯远了哈

我先说一下我的持续集成思路

  • 我想到这个的背景:上面也说过了,是我桃大佬提供的(他超棒)。主要是为了解决hexo博客平台无法备份代码源码的问题,因为我如果没有备份的源码,万一我本地的存储系统崩盘了之后,我不就蛋糕了吗?!!!所以现在搭建好这一系统后,如果遇到了本地存储系统崩盘的情况,我们可以从云端(GitHub)上下载代码,实现本地重建。
  • 我的持续集成思路:我的博客源码存储在GitHub上的一个独立的仓库(上图中的GitHubSource)中,博客hexo自动生成的静态文件又是在另外一个独立的仓库(GitHubgitpage)中,每次我在本地把代码推到我的GitHub仓库之后,Travis就会立刻监听到我仓库发生了变动,这个时候Travis就会采取反制措施,具体我后面再细讲。反制措施会生成原本本地就可以生成的博客网站静态文件,并把文件部署到GitHubPage上面。

图解:

Step1:这一步骤,我是将本地的代码推到GitHub上的GitHubSource仓库中去。 Step2:这一步骤得细讲,我们GitHub的好兄弟——Travis在第一时间发现了我存储在GitHubSource仓库里的代码发生了变动(此处就是我Step1中的推代码行为导致的变动,实际生活中也可能是删掉代码之类的其他操作导致的仓库变动),于是它做的第一件事情就是将变动后的代码拉到它自己的虚拟机上,我更愿意将它理解为虚拟机(实际上不是虚拟机哦!)。 Step3:虚拟机接下来会检查拉到本地的源码中是否会存在.travis.yml文件,该文件里边就有指示Travis CI本地虚拟机的命令,下面我详解一下该文件哈!现在我们只要知道该命令可以像本地hexo那样将博客源代码进行编译,生成静态文件。 Step4:接下来我就要向大家补充或者说巩固一个知识点了:hexo博客平台每一次的hexo三连(hexo c && hexo g && hexo d),最后都只是将博客中的public文件部署(上传)到GitHubPage而已。于是咱们的第四步就是将在Travis CI虚拟机中生成的静态文件上传到我的GitHubPage仓库中去。至此,大功告成!

.travis.yml文件详解

先放上我的文件,可以信赖哦!

language: node_js

node_js: stable # 要安装的node版本为稳定版

cache:
directories:
- node_modules # 要缓存的文件夹

install:
- npm install

script:
- hexo clean
- hexo g

after_script:
- cd ./public
- git init
- git config user.name "mr8god"
- git config user.mail "17696748602@163.com"
- git add .
- git commit -m "代码使用Travis CI自动部署的哈"
- git push --force --quiet "https://${blogsource}@${GH_REF}" master:master

branches:
only:
- master # 触发持续集成的分支。现在我们源码在哪里,这边就填哪一个分支,如果该分支发生变化,那么就会启动travisCI


env:
global:
- GH_REF: github.com/Mr8god/Mr8god.github.io.git

参数讲解:

-language:指定Travis CI的基本环境语言,我这边选择的是hexo的基本环境原因——nodejs -node_js:选择安装的node版本,对咯对咯,每一次使用Travis CI的虚拟机都会是一幅全新的模样,该虚拟机每一次的操作都需要安装对应的环境。 -cache:缓存文件存储的位置 -install:这里边我选择了 npm install命令,安装hexo博客平台需要的一些依赖包。 -script:脚本行为开始,可以看到我这边是本地很正常的hexo clean和hexo g命令,不做解释哈。执行完这两个行为后,我们会在虚拟机的public文件夹中生成我们需要的静态网页文件。 -after_script:如其名,执行完脚本后该干什么呢?这边的一串命令是为了将虚拟机的public文件夹中的静态文件上传到GitHubPage仓库中去,实现部署。 -branches:里边填上我们Travis CI所监督的GitHub仓库的分支,只要这个分支出现了代码变动,就会有接下来一波反制措施。 -env:介里边是变量。

综上介绍完了,如果你要用我的配置文件的话,你需要把- git config user.name "mr8god"、 - git config user.mail "17696748602@163.com"、-GH_REF: github.com/Mr8god/Mr8god.github.io.git或者再加上那个分支的内容改一改,改成自己的东西就行了。

实操

这个也是挺重要的!

首先我们在我们的GitHub上建好我用于存放源码的仓库哦!接下来就需要打开GitHub的setting进行GitHub与它好兄弟Travis CI的故事了

GitHub与Travis CI进行token绑定

首先我们打开我们的GitHub主页面,进入我们的setting里,发现了deployer setting 实操(一).jpg

我们点进去,接下来会看到下图 实操(二).jpg

然后继续点我的红圈 实操(三).jpg

然后继续点我的红圈,我们开始创建token了 实操(四).jpg

这边我们要记住我们的note,因为接下来在Travis CI页面我们用得上。

实操(五).jpg

然后这边的这个值也一定要记住!!!这个时候就该把它复制下来了,因为这个页面只会显示一次,如果你错过了,你就得重来亿遍!

实操(六).jpg

接下来,在前一个name的红圈内填上我们的note,后边的value中填上我们刚刚复制的码。就OK了,就实现了这个仓库和我们GitHub仓库的绑定。

【一个常见的错误】:我们在观测代码变动时,在Travis CI的Build History中可能会遇到不管怎么push,依旧 纹丝不动的情况,这个时候就要注意看看自己的.travis.yml文件是否是完整无缺,没有错误的。

在博客文件上我们要做些什么呢?

我们需要在博客文件的根目录下添加我们上面详解的.travis.yml文件,就行了。接下来就是一个容易出错的重点了,而且比较难免描述清楚,我尽力用我的语言描述清楚哈。

如何将本地的hexo博客源码push到GitHub上的source仓库中去

这个地方是困扰我很久的地方,如果这个地方没有做好的话,我们会面临一个直观的问题,我们部署好之后的网站是一片空白,

为什么呢? 因为我们的渲染文件没有部署上去呀!

为什么我们的渲染文件没有部署上去呢? 因为我们源码中的next主题(hexo的一种博客主题)没有push到我们的云端GitHub的source仓库呀!

为什么我们的next主题文件会没有push到我们的云端GitHub上的source仓库中去呢? 这个就要说到我们当初创建本地博客文件的时候了,那个时候我没有注意一个问题,我直接主题源码仓库把代码pull到本地了,这导致了我们的theme——next文件中本身就有一个初始化过、指向原仓库的git了,这构成了git的一种叫做submodule(子模块,就是git文件中还有一个git文件),

这会导致什么结果呢? 会导致本地的next文件夹无法上传到我们的GitHub源代码仓库中去, 进而无法被我们的Travis CI拉到它的虚拟机中去, 进而无法生成CSS、js等网站渲染文件, 进而出现了我们开头所讲到的一片空白现象。

这一点提醒了我,日后在pull别人代码的时候,要做分离处理!!!

那我们该怎么解决呢?

【解决方法】

  1. 首先我们来到我们的next文件夹(博客目录/themes/next)下,删掉.git和.gitnore文件
  2. 然后cd到我们的themes文件夹目录下,清除缓存。命令是:git rm -r --cached next
  3. 然后就是Git三连了(git add . 、 git commit -m "想说啥说啥" 、 git push)
  4. 完美解决问题,别看这么简单,我花了三小时……

大功告成,睡了睡了

有问题联系我江某人哈

QQ:1803357141

img